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

[José Fonseca]

On Tue, 2010-05-11 at 07:45 -0700, Marek Olšák wrote:
> 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.

OK. Sounds reasonable.

I'll do that change and commit tomorrow if nobody has more remarks. I
need to write up some docs too.

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

I was referring to D3D shader models. HW vendors have might have their
own internal engine revs, but they clearly follow the D3D specs.

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

Yes.

Jose