[Mesa-dev] [PATCH v2 1/2] mesa: Add a gl_vert_result for gl_ClipVertex.

[Paul Berry]

On 4 October 2011 14:49, Brian Paul <brianp at vmware.com> wrote:

> On 10/04/2011 03:19 PM, Paul Berry wrote:
>
>> On 4 October 2011 13:15, Ian Romanick <idr at freedesktop.org
>> <mailto:idr at freedesktop.org>> wrote:
>>
>>    On 10/03/2011 02:17 PM, Paul Berry wrote:
>>
>>        Before this patch, clip planes didn't work properly in Mesa
>>        when using
>>        vertex shaders, because Mesa assigned both gl_ClipVertex and
>>        gl_Position to the same gl_vert_result (VERT_RESULT_HPOS).  As a
>>        result, backends couldn't distinguish between the two
>>        variables, so
>>        any shader that wrote different values to them would fail to work
>>        properly.
>>
>>        This patch paves the way for proper support of gl_ClipVertex by
>>        creating a new enumerated value in gl_vert_result for it
>>        (VERT_RESULT_CLIP_VERTEX).  After this patch, a back-end may add
>>
>>
>>    What happens in drivers that aren't expecting / don't know about
>>    VERT_RESULT_CLIP_VERTEX?  In other words, does this break (more)
>>    i915 and all Gallium drivers?  I understand that gl_ClipVertex
>>    already doesn't work anywhere, but it would be a shame to replace
>>    incorrect rendering with a crash.
>>
>>    I can test out (and patch up) i915 today, but I'd like some
>>    feedback from people that rely on TGSI.
>>
>>
>> Dang, I should have thought of this.
>>
>> BTW, an easy way to assess the effect of this patch on a driver would
>> be to run Piglit with "-t clip" after applying this patch.  The patch
>> should only regress "vs-clip-vertex-const-reject" (which only used to
>> pass by dumb luck), and nothing should crash or abort.  Also, if
>> "clip-plane-transformation fixed" passes, we can have pretty high
>> confidence that old fashioned fixed function clipping still works.
>>
>> I just did this test on Gallium's LLVM pipe and on vanilla swrast, and
>> everything looked ok--no regressions other than
>> vs-clip-vertex-const-reject.  BTW, both gallium LLVM pipe and vanilla
>> swrast have a crash (in "vs-clip-vertex-enables" and
>> "clip-plane-transformation arb", respectively), but in both cases the
>> crash seems to be unrelated to this patch.
>>
>
> Can you show me the command lines to run these?  I can't find
> vs-clip-vertex-enables


Oh yeah, some of those tests haven't landed yet--they're in a 3-patch series
I sent to the Piglit list yesterday afternoon.  If one of you wants to give
me a "Reviewed-by" on the Piglit list I'll commit them to master.  In the
meantime you can get them from branch "clip-plane-transformation" on git://
github.com/stereotype441/piglit.git.


>
>
>
>  Unfortunately I don't have the hardware to test anything else so I'd
>> appreciate feedback from others.
>>
>> If worse comes to worst and we do wind up regressing a driver, I
>> suppose a workaround would be to add a flag to
>> gl_shader_compiler_options so that the driver can tell the GLSL
>> compiler either "I understand VERT_RESULT_CLIP_VERTEX" or "I don't,
>> just do the old buggy behavior".  But it seems ugly so I would rather
>> avoid that sort of thing if we can.
>>
>
> Gallium doesn't support clip distances yet so we might have to work on
> that.  If you've tested llvmpipe and it looks OK, that's enough for me at
> this point.
>
> -Brian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111004/401200c1/attachment.htm>