[Mesa-dev] [PATCH] gallium: add TGSI_SEMANTIC_TEXCOORD,PCOORD

[Christoph Bumiller]

On 13.03.2013 21:24, Jose Fonseca wrote:
> ----- 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.
> 

Sure, ok, I just though it would fit better up there, having PSIZE and
PCOORD adjacent. Binary compatibility issues ?

So far so good, now I just have to fear the other driver devs' wrath (or
silence) for changing something that already works for them ...

> Jose
>