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 <jfons...@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 <jfons...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
