Jose Fonseca jfonseca at vmware.com
Wed Mar 13 13:24:15 PDT 2013

----- Original Message -----
> Second attempt, 2 years ago no one replied or cared ...
> We really need to know about these on nvc0 because there are only 8
> fixed hardware locations that can be overwritten by sprite coordinates,
> and one location that represents gl_PointCoord and unconditionally
> returns sprite coordinates.
> So far this was solved via a hack, which works since the locations the
> state tracker picks aren't dynamic (and likely will never be, to facilitate
> ARB_separate_shader_objects), but it still isn't nice to do it this way.
> It looks like nv30 was using a hack, too, since it had a check for
> Semantic.Index == 9, which is what mesa uses for PointCoord.
> Implementing a safe, non-mesa-dependent way without these SEMANTICs would
> be jumping through hoops and doing expensive shader recompilations just
> because we like to destroy information at the gallium threshold, and that's
> unacceptable.
> I started to (try) fix up the other drivers, but maybe we just want a CAP
> for this instead, since the default solution - if this is TEXCOORD then
> treat it as GENERIC with semantic index += MAX_TEXCOORDS - doesn't really
> look that nicer either.
> E.g. if PIPE_CAP_RESTRICTED_SPRITE_COORDS is advertised, the state tracker
> should use the TEXCOORD and PCOORD semantics, otherwise it should just use
> GENERICs as before.

Personally I have no objection with this FWIW.

But please append the new TGSI_SEMANTIC_xxx without renumbering the existing ones.


More information about the mesa-dev mailing list