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

Christoph Bumiller e0425955 at student.tuwien.ac.at
Tue Dec 13 13:18:18 PST 2011


On 12/13/2011 09:58 PM, Jose Fonseca wrote:
> 
> 
> ----- Original Message -----
>> On 12/13/2011 09: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 ?
>>>
>>>
>>> Could you also elaborate on why TGSI_SEMANTIC_CLIPDIST is useful
>>> for the drivers? I personally don't have nothing against it, but
>>> just like to understand why it makes a difference.
>>>
>>
>> Why does TGSI_SEMANTIC_*POSITION* make a difference ?
>>
>> Right, because the position values are consumed by the fixed function
>> rasterizer. So are the clip distances.
>>
>> This is not about pipe_clip_state.ucp but about what this legacy
>> cruft
>> has to be turned into if GL_CLIP_PLANEi is used instead of GLSL 1.3's
>> gl_ClipDistance[i].
> 
> I'm just surprised because I thought there was no more fixed function clipping.
> 

nvfx and r300, and I think even r600, are probably happy to have UCPs in
the interface and can make direct use of them, see nvfx_ucp_validate in
nvfx_state_emit.c or r300_set_clip_state in r300_state.c

nv50 and nvc0 have to use the same shader outputs for both legacy
glClipPlanes and gl_ClipDistance[].

On nv50, there is shader-external state that designates which outputs
are clip distances, on nvc0 they have to be written to special output
slots/addresses so the semantic information is important to be able to
assign slots at compile time (the GPU was specially designed to make
this possible and to support ARB_separate_shader_objects nicely).

In D3D10/11, there is a system value semantic for clip distances and
cull distances (cull distance is a different clipping mode and consumes
the same slots as clip distances).
See
http://msdn.microsoft.com/en-us/library/windows/desktop/bb509647%28v=vs.85%29.aspx.


More information about the mesa-dev mailing list