[Mesa-dev] RFC: Fine grained caps for shader limits
José Fonseca
jfonseca at vmware.com
Tue May 11 06:53:15 PDT 2010
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
More information about the mesa-dev
mailing list