[Mesa-dev] RFC: Fine grained caps for shader limits
Keith Whitwell
keithw at vmware.com
Wed May 12 02:33:56 PDT 2010
On Tue, 2010-05-11 at 15:01 -0700, José Fonseca wrote:
> 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.
I think the early history is a bit muddier than that - some of the sm2
varients were clearly driven by specific IHVs rather than centralized
microsoft dictat.
In some ways these are the easiest to ignore - they can be regarded as
intermediate steps on the way to SM3 which didn't have widespread
hardware support -- the equivalent of GL vendor-specific shader
extensions.
Keith
More information about the mesa-dev
mailing list