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