Created attachment 79404 [details] archive with sources to test Description of problem: Clipping is performed incorrectly when using shaders with intel/nouveau/radeon drivers. Test to reproduce the bug: download attachment tar xvf opengl-clipping-plane-bug.tar.xz cd opengl-clipping-plane-bug make ./test Use SPACE to toggle between shader state (enable/disable). This simple test draws a quad with vertices coordinates (0,0,0), (640,0,0), (640,480,0), (0,480,0) and setup a clipping plane with plane equation coefficients (1,0,0,0), model view is identity. According to documentation http://www.opengl.org/sdk/docs/man2/xhtml/glClipPlane.xml all vertices must be in clipping plane, but when using shaders half of quad is clipped instead. Version-Release number of selected component (if applicable): Xorg: 1.14.1-1.fc19.x86_64 mesa: 9.2-0.1.20130508.fc19.x86_64 xorg-x11-drv-intel: 2.21.6-1.fc19.x86_64 xorg-x11-drv-nouveau: 1.0.7-1.fc19.x86_64 and X.Org X Server 1.12.3 mesa-libGL-8.0.4-1 xorg-x11-drv-intel-2.20.8-1 xorg-x11-drv-nouveau-0.0.16-37 How reproducible: Always. Actual results: Object is half-clipped. (see screenshot "intel-i915-with-shader.png" "nvidia-Nouveau-with-shader.png") Expected results: Object is fully shown. (see screenshot "amd-Catalyst-with-shader.png" "nvidia-NVIDIA-with-shader.png")
Created attachment 79405 [details] intel-i915-with-shader
Created attachment 79406 [details] intel-i915-without-shader
Created attachment 79407 [details] nvidia-Nouveau-with-shader.png
Created attachment 79408 [details] nvidia-Nouveau-without-shader
Created attachment 79409 [details] amd-Catalyst-with-shader
Created attachment 79410 [details] amd-Catalyst-without-shader
Created attachment 79411 [details] nvidia-NVIDIA-with-shader
Created attachment 79412 [details] nvidia-NVIDIA-without-shader
Confirmed. chipset: 6 series mesa: 8.0.4 xorg-x11-drv-intel: 2.21.5 xserver: X.Org X Server 1.12.4 libdrm: 2.4.42 Linux distribution: Fedora 17
I was able to reproduce this behavior on Ivybridge with Mesa master, so it's not just a 8.x bug.
(In reply to comment #10) > I was able to reproduce this behavior on Ivybridge with Mesa master, so it's > not just a 8.x bug. Yes. I'm using git version. Videocard: Intel HD4000.
I've verified that your test passes with the nVidia proprietary driver. However I'm not yet convinced this is a bug in Mesa, and here's why: This test is exercising a corner case which the spec are somewhat contradictory about: what happens when user clip planes are in use but a shader does not write to gl_ClipVertex? - All versions of OpenGL from 2.0 onward clearly state that the behaviour is undefined. - GLSL 1.10 and 1.20 specs say that the behaviour is undefined. - GLSL 1.30 through 4.10 specs say that clipping is performed using gl_Position*. - GLSL 4.20 onward say that the behaviour is undefined. Additionally, the "Changes from revision 8 of Version 4.20" section of the spec says "Make GLSL consistent with the API regarding user clipping, by no longer referring to gl_Position when gl_ClipVertex is not written. Rather, user clipping becomes undefined." *Even in the GLSL 1.30 through 4.10 case, the behaviour is poorly defined: OpenGL says that clip planes are specified in "object coordinates" and are then converted to "eye coordinates" by OpenGL at the time they are specified. When gl_ClipVertex is in use, it is assumed to be in eye coordinates too. However, gl_Position uses "clip coordinates". So, in the case where clipping is performed using gl_Position, should the coordinates be transformed to match, or should the clipping be performed directly using gl_Position, in spite of the coordinate system mismatch? A literal reading of the spec seems to indicate that clipping should be performed directly using gl_Position--this is the interpretation Mesa uses. As a result of the coordinate system mismatch, clipping using gl_Position is usually counterintuitive, and doesn't match the behaviour of the fixed function pipeline. In the case of your test, that manifests as the left half of the window getting clipped, since the left half of the window has a negative value of gl_Position.x. As far as I've been able to tell from experimenting with the nVidia proprietary driver, its behaviour in this corner case is to not clip at all. That causes your test to pass, but not because clipping is being performed in the way you expect. So I'm a little bit loathe to "fix" the bug by changing Mesa to match nVidia behaviour. Instead, my recommendation would be to change the test to avoid exercising the undefined/poorly-defined behaviour. If you add this line to the vertex shader: gl_ClipVertex = gl_ModelViewMatrix * gl_Vertex; you will get the expected clipping behaviour from both Mesa and proprietary drivers.
> As far as I've been able to tell from experimenting with the nVidia > proprietary driver, its behaviour in this corner case is to not clip at all. You're absolutely correct, it doesn't clip. I see that OpenGL specification is a garbage. :) In this case I'm mostly interested in portability and compatibility, since it doesn't clip in both Windows and Linux with proprietary drivers, it seems logical to implement such behaviour for much less spread open implementation mesa and open drivers...
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.