Bug 45913

Summary: [r300g] piglit vs-clip-vertex-const-reject fails
Product: Mesa Reporter: Pavel Ondračka <pavel.ondracka>
Component: Drivers/Gallium/r300Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: low CC: stereotype441
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Pavel Ondračka 2012-02-10 13:57:38 UTC
Found while comparing piglit runs on r300g RV530 between 7.11 and 8.0. 
llvmpipe is also affected.

7d68c639ddb0f9df45cf698b8e8227bf1860b5fe is the first bad commit
commit 7d68c639ddb0f9df45cf698b8e8227bf1860b5fe
Author: Paul Berry <stereotype441@gmail.com>
Date:   Mon Sep 26 13:15:57 2011 -0700

    mesa: Add a gl_vert_result for gl_ClipVertex.
    
    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
    support for gl_ClipVertex using the following algorithm:
    
    - If using a user-supplied GLSL vertex shader:
      - If the bit corresponding to VERT_RESULT_CLIP_VERTEX is set in
        gl_program::OutputsWritten:
        - Clip using the vertex shader output VERT_RESULT_CLIP_VERTEX and
          the clip planes defined in gl_context::Transform.EyeUserPlane.
      - Else:
        - Clip using the vertex shader output VERT_RESULT_HPOS and the
          clip planes defined in gl_context::Transform.EyeUserPlane.
    - Else (either using fixed function or an ARB vertex program):
      - Clip using the vertex shader output VERT_RESULT_HPOS and the clip
        planes defined in gl_context::Transform._ClipUserPlane (*)
    
    where (*) represents the normal Mesa behavior before this patch.
    
    An example of implementing the above algorithm can be found in the
    patch that follows this one, which implements gl_ClipVertex in i965
    Gen6.
    
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

My system:
GPU: RV530
Mesa: a8cc228edd1dd6328f8b9086d768b52f821c6575
Kernel: 3.2.3
Libdrm 2.4.31
Comment 1 Paul Berry 2012-02-10 15:22:48 UTC
Before commit 7d68c639ddb0f9df45cf698b8e8227bf1860b5fe, Mesa's support for gl_ClipVertex was completely broken, because Mesa couldn't distinguish between gl_ClipVertex and gl_Position.  The bugs in Mesa happened to line up in such a way that the Piglit test vs-clip-vertex-const-reject passed, but this was not a sign that gl_ClipVertex in any way worked; it was just a coincidence.

Commit 7d68c639ddb0f9df45cf698b8e8227bf1860b5fe laid the groundwork for actual non-buggy support for gl_ClipVertex, and a later patch.  However, it was impossible to lay this groundwork without causing vs-clip-vertex-const-reject to stop passing.  This is not a true regression, because vs-clip-vertex-const-reject was only passing by dumb luck before this commit; it wasn't passing because of any correct functionality in Mesa.

In order for gl_ClipVertex to work on any particular driver (for example r300g or llvmpipe), additional back-end work needs to be done.  I have done this back-end work for i965 (see commit d912669034eb7bf5c162358a7a574ec7a4c963c7).  However, I don't have the expertise to do it for other back-ends.  If anyone who is knowledgeable about r300g RV530 or llvmpipe would like to do the corresponding back-end work for those drivers, I would be happy to help--feel free to email me at stereotype441@gmail.com if commit d912669034eb7bf5c162358a7a574ec7a4c963c7 doesn't provide enough information.

Incidentally, the same situation also exists for i915.
Comment 2 Pavel Ondračka 2012-02-11 00:24:49 UTC
OK, reassigning to r300g per commment 1. Also lowering importance.
Comment 3 GitLab Migration User 2019-09-18 18:50:41 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/340.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.