[Mesa-dev] RFC: Fine grained caps for shader limits

[Marek Olšák]

On Tue, May 11, 2010 at 12:49 PM, José Fonseca <jfonseca at vmware.com> wrote:

> Attached is my proposal for fine grained caps for shader limits.
>

I'd like have a cap for MaxNativeAluInstructions too. ;) Otherwise it looks
good.

On Tue, May 11, 2010 at 3:53 PM, José Fonseca <jfonseca at vmware.com> wrote:

> Hardware tends to follow these shader models.


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. ;)


> And it's not just a matter
> of advertising support -- if the state tracker can't actually use
> alternative instructions then nobody cares that hardware XXX can support
> all SM Y opcodes except opcode ZZZ. The driver implementor might as well
> only implementing SM Y-1, or tries to describe ZZZ efficiently in terms
> of other ops.
>
> I think that lumping capabilities in shader models and have the state
> trackers and drivers fit into them is a better compromise IMO.
>
> However we can and should start constructing a catalog of which
> instructions are part of which SM.
>

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.

-Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100511/5014ee51/attachment.htm>