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
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.
OK, reassigning to r300g per commment 1. Also lowering importance.
-- 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.