Bug 64668

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...