Sorry that trace is a bit too much to handle. I looked at it but I can't really make out any difference wrt use of glsl shader or not at all (note that for the gallium driver this cannot make a difference in any case as it has no idea if you used glsl or not, though in theory there could be slight differences depending on how ftransform() is implemented). Just about the only thing I noticed is that the actual geometry is different between the two... Could you tell me at what call number this is?
Also it looks like it has depth test enabled as well, I'm not entirely sure if or how clipping would affect interpolated depth, though nothing bad should happen.

I found out that the problem is the line:

gl_ClipVertex = gl_ModelViewMatrix * gl_Vertex;

in the fragment shader. If I remove that line, it works as expected.

Since the rendering is ok on ATI/NVidia and on softpipe, I suspect that
gl_ClipVertex support is broken in LLVM pipe.

(In reply to comment #2)
> I found out that the problem is the line:
> 
> gl_ClipVertex = gl_ModelViewMatrix * gl_Vertex;
> 
> in the fragment shader. If I remove that line, it works as expected.
> 
> Since the rendering is ok on ATI/NVidia and on softpipe, I suspect that
> gl_ClipVertex support is broken in LLVM pipe.

Are you sure you're seeing that in the fragment shader?  Vertex-related code like that would normally be seen in the vertex shader.

Sorry, that was a typo, of course it is in the vertex shader.

Reassigning to mesa core.
Though in my testing this seems to be *both* a core and a draw problem.
With my piglit test the first error (without redrawing) appears with 4097 vertices - despite that the vbo code can handle 5460 (per vertex size is just 12 bytes) without splitting.

Oops wrong bug. Disregard last comment...

(In reply to comment #2)
> I found out that the problem is the line:
> 
> gl_ClipVertex = gl_ModelViewMatrix * gl_Vertex;
> 
> in the fragment shader. If I remove that line, it works as expected.
> 
> Since the rendering is ok on ATI/NVidia and on softpipe, I suspect that
> gl_ClipVertex support is broken in LLVM pipe.

Actually I suspect gl_ClipVertex is mostly ok, but you're writing garbage to it and relying on the fact that user plane clipping is disabled so the output isn't actually used. Or something like that. This is where we failed (using the clipvertex output for ordinary clipping even if user plane clipping is disabled). Patch coming...

Fixed by 6d2ecdb4a63350cfeee803c00ac283ee013a5ee5.

I also observe this problem, but I have used a really new mesa version:
OpenGL 3.0 Mesa 10.5.3
Gallium 0.4 on llvmpipe (LLVM 3.6, 256 bits)

To get an impression how the clipping looks, I have attached some snapshots:
* snapshot_1.png: clipping is active (axis aligned clipping cube) and all possibly clipped triangles are in the viewport -> clipping works as expected.
* snapshot_2.png/snapshot_3.png: after zooming in a little bit, most triangles that have a clipped vertex are clipped completely.

Additional information:
* We do the clipping within a GLSL shader with gl_ClipVertex (not fixed function).
* Reproducible on windows and linux llvmpipe version -> I did not expect any difference, but who knows...
* Using nvidia hardware rendering with the same shader code looks correct.
* Because the clipping is working correct when all triangles are within the viewport, I don't expect a shader problem.

Created attachment 115588 [details]
all clipped triangles are within the viewport

Created attachment 115589 [details]
triangles get completely clipped on viewport - 1

Created attachment 115590 [details]
triangles get completely clipped on viewport - 2

Does this happen with other gallium based drivers (softpipe for instance, though it might hit all the same code)?
I'm afraid noone will look into it without an apitrace trace (or some sample code like a piglit test).

The problem is also reproducible with softpipe.

I understand your concern and I will try provide some samplecode to reproduce the clipping error.

cgerlach42, does this still happen?
There were some more clip fixes very recently.
If this still happens you really need to provide either sample code or an apitrace.

I have checked mesa version 10.6.9 and 11.0.7 both with llvm 3.4 and the clipping problem is still reproducible here.

I have also tried to provide an apitrace. The tool works fine, as long as I stick to hardware rendering (where the problem does not occur). For software rendering the context creation fails. I'm hoping that I will find a solution for this...

(In reply to cgerlach42 from comment #16)
> I have checked mesa version 10.6.9 and 11.0.7 both with llvm 3.4 and the
> clipping problem is still reproducible here.
That would be too old for these fixes, only mesa master would do.

> 
> I have also tried to provide an apitrace. The tool works fine, as long as I
> stick to hardware rendering (where the problem does not occur). For software
> rendering the context creation fails. I'm hoping that I will find a solution
> for this...

You don't need the same driver to capture the trace. As long as your app sticks to things which is supported by both this should work. Though of course depending on the reasons why context creation fails it might just fail on replay too.

You were right, the latest mesa version fixes this problem :-)

Latest git hash from my checkout is:
e97b207654a1c0b2c27b6ad6579b5570a83ce8cd

I also tried to replay an apitrace generated with hardware rendering, but I can't get the glretrace to use software rendering. It always uses the systems opengl32.dll and therefore the clipping problem is not reproducible.

(In reply to cgerlach42 from comment #18)
> I also tried to replay an apitrace generated with hardware rendering, but I
> can't get the glretrace to use software rendering. It always uses the
> systems opengl32.dll and therefore the clipping problem is not reproducible.

If you put Mesa opengl32.dll into the same dir as glretrace.exe it should work.

Alternatively, you can do


  set TRACE_LIBGL=C:\path\to\desired\opengl32.dll
  glretrace foo.trace

Ok let's close it then.
FWIW I suspect 9e3f2af3c3732bd618308ddeffb017966a4fc93e fixed it (this applies if you were writing gl_ClipVertex and have enabled at least one clip plane).