On Tue, 2010-05-11 at 06:38 -0700, Jakob Bornecrantz wrote: > On 2010-05-11 11.49, José Fonseca wrote: > > Attached is my proposal for fine grained caps for shader limits. > > > > These don't cover which opcodes are supported, so PIPE_CAP_GLSL and > > PIPE_CAP_SM3 remains. I think that PIPE_CAP_SM3 should be rename to > > PIPE_CAP_SM, which shader model major/minor version encoded in a dword. > > PIPE_CAP_GLSL could probably be derived from everything else. > > > > Since we are moving to fine grade caps wouldn't it be better if we just > added caps for the actual instructions instead of having these meta > caps. Maybe not for each individual instruction but for groups > (flowctrl, derive, etc). Just a thought.
Hardware tends to follow these shader models. 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 looked at the patches and they look good to me. > > Cheers Jakob. Thanks. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
