<div class="gmail_quote">On Tue, May 11, 2010 at 12:49 PM, José Fonseca <span dir="ltr"><<a href="mailto:jfonseca@vmware.com">jfonseca@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Attached is my proposal for fine grained caps for shader limits.<br></blockquote></div><br>I'd like have a cap for MaxNativeAluInstructions too. ;) Otherwise it looks good.<br><br><div class="gmail_quote">On Tue, May 11, 2010 at 3:53 PM, José
Fonseca <span dir="ltr"><<a href="mailto:jfonseca@vmware.com">jfonseca@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hardware tends to follow these shader models.</blockquote><div><br>I think shader models rather tend to follow hardware, how else could we end up with sm2.0 (R300), sm2.0a (GF FX), and sm2.0b (R400)? BTW sm2.0a does support some flow control but sm2.0b doesn't. BTW Intel have jumped in too late so they haven't got their own shader model. ;)<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> And it's not just a
matter<br>
of advertising support -- if the state tracker can't actually use<br>
alternative instructions then nobody cares that hardware XXX can support<br>
all SM Y opcodes except opcode ZZZ. The driver implementor might as well<br>
only implementing SM Y-1, or tries to describe ZZZ efficiently in terms<br>
of other ops.<br>
<br>
I think that lumping capabilities in shader models and have the state<br>
trackers and drivers fit into them is a better compromise IMO.<br>
<br>
However we can and should start constructing a catalog of which<br>
instructions are part of which SM.<br></blockquote><div><br>I think some (all?) arithmetic instructions can be converted to several simple/supported ones. E.g R300 fragment shaders can do CMP but not SGE/SLT, R300 vertex shaders can do SGE/SLT but not CMP. We have transformation functions between the two in the compiler. And I could go on... I guess it's clear we should only care about opcodes which cannot be emulated.<br>
<br>-Marek<br></div></div>