[Nouveau] [RFC PATCH 00/11] Implement ARB_cull_distance

[Marek Olšák]

It looks like we would benefit from sharing the lowering code.

Having a GLSL compiler pass that does this would be useful:

for (i = 0; i < gl_MaxCullDistances; i++)
   gl_ClipDistance[gl_MaxClipDistances+i] = gl_CullDistance[i];

And it should be run based on a PIPE_CAP.

Marek


On Wed, Jul 8, 2015 at 10:06 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Wed, Jul 8, 2015 at 4:04 PM, Tobias Klausmann
> <tobias.johannes.klausmann at mni.thm.de> wrote:
>>
>>
>> On 25.05.2015 17:07, Ilia Mirkin wrote:
>>>
>>> On Mon, May 25, 2015 at 9:40 AM, Tobias Klausmann
>>> <tobias.johannes.klausmann at mni.thm.de> wrote:
>>>>
>>>> On 25.05.2015 07:17, Dave Airlie wrote:
>>>>>
>>>>> On 25 May 2015 at 08:11, Marek Olšák <maraeo at gmail.com> wrote:
>>>>>>
>>>>>> It's the same on Radeon. There are 2x ClipOrCullDistance output
>>>>>> vectors and a mask saying it should clip or cull or do nothing.
>>>>>>
>>>>>> Marek
>>>>>>
>>>>> My thinking was gallium should have a single semantic and a mask in
>>>>> the shader definition maybe.
>>>>>
>>>>> though it doesn't solve the does nvidia do the right thing with
>>>>> cull[0] and clip[0], and what is the right thing.
>>>>>
>>>>> Dave.
>>>>
>>>>
>>>> I'm still convinced that both clip[0] and cull[0] should be possible.
>>>> Plus i
>>>> have written a shader_test for this a while ago which you pushed to
>>>> piglit
>>>> (fs-cull-and-clip-distance-different.shader_test). If i remember right
>>>> nvidia passed that test just fine.
>>>
>>> My take (and note that I last read the extension many months ago) is
>>> that you're supposed to figure out the max gl_ClipDistance[] written,
>>> and then write all your cull distances above that. So if you, e.g.,
>>> have something like
>>>
>>> gl_ClipDistance[5] = 1;
>>> gl_CullDistance[0] = 1;
>>>
>>> Then it would decide that there are 6 clip distances (or if there's an
>>> explicit out float gl_ClipDistance[n], then use that), and 1 cull
>>> distance. In the TGSI, I'm thinking this might look approximately like
>>>
>>> PROPERTY CULL_MASK (1<<6)
>>> DCL OUT[0], CLIPDIST[0]
>>> DCL OUT[1], CLIPDIST[1]
>>> MOV OUT[1].y, 1 (clip distance[5])
>>> MOV OUT[1].z, 1 (cull distance[0])
>>>
>>> Then basically you'd have
>>>
>>> (rast->clip_enable & shader->actual_clip_writes_mask) | cull_mask =
>>> the enabled distances
>>> cull_mask = cull mask
>>>
>>> This would work *very* well for nouveau, not sure how suitable it is
>>> for other hardware.
>>>
>>> Cheers,
>>>
>>>    -ilia
>>
>> I wonder where this step should be implemented after all. It was brought up
>> that llvmpipe already supports cull_distance (it does!), so maybe we should
>> implement this in the drivers to evade llvmpipe breakage. Any suggestions
>> appreciated :)
>>
>> Tobias
>
> I believe that the later feedback from Brian was that my approach was
> a bad one and we should use CULLDIST instead, which also reflects how
> GL has it. However it's important to specify *somewhere* how many clip
> distances are used since it all gets lowered into the 2x vec4. It
> might be annoying to derive it from writes to CLIPDIST[0/1].xyzw dest
> masks. Although nouveau might already do that anyways...
>
>   -ilia