[Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium

[Bryan Cain]

On 12/13/2011 03:09 PM, Jose Fonseca wrote:
>
> ----- Original Message -----
>> On 12/13/2011 12:26 PM, Bryan Cain wrote:
>>> On 12/13/2011 02:11 PM, Jose Fonseca wrote:
>>>> ----- Original Message -----
>>>>> This is an updated version of the patch set I sent to the list a
>>>>> few
>>>>> hours
>>>>> ago.
>>>>> There is now a TGSI property called
>>>>> TGSI_PROPERTY_NUM_CLIP_DISTANCES
>>>>> that drivers can use to determine how many of the 8 available
>>>>> clip
>>>>> distances
>>>>> are actually used by a shader.
>>>> Can't the info in TGSI_PROPERTY_NUM_CLIP_DISTANCES be easily
>>>> derived from the shader, and queried through
>>>> src/gallium/auxiliary/tgsi/tgsi_scan.h ?
>>> No.  The clip distances can be indirectly addressed (there are up
>>> to 2
>>> of them in vec4 form for a total of 8 floats), which makes it
>>> impossible
>>> to determine which ones are used by analyzing the shader.
>> The description is almost complete. :)  The issue is that the shader
>> may
>> declare
>>
>> out float gl_ClipDistance[4];
>>
>> the use non-constant addressing of the array.  The compiler knows
>> that
>> gl_ClipDistance has at most 4 elements, but post-hoc analysis would
>> not
>> be able to determine that.  Often the fixed-function hardware (see
>> below) needs to know which clip distance values are actually written.
> But don't all the clip distances written by the shader need to be declared?
>
> E.g.:
>
> DCL OUT[0], CLIPDIST[0]
> DCL OUT[1], CLIPDIST[1]
> DCL OUT[2], CLIPDIST[2]
> DCL OUT[3], CLIPDIST[3]
>
> therefore a trivial analysis of the declarations convey that?

No.  Clip distance is an array of up to 8 floats in GLSL, but it's
represented in the hardware as 2 vec4s.  You can tell by analyzing the
declarations whether there are more than 4 clip distances in use, but
not which components the shader writes to. 
TGSI_PROPERTY_NUM_CLIP_DISTANCES is the number of components in use, not
the number of full vectors.

Bryan