Using gl_PrimitiveId with mesa 10.5.3 on Linux (running in a Virtualbox VM on windows) I am seeing glPrimitiveId increment up to 339 and then it resets back to zero and starts incrementing again. Yeh, 0-339, that's funky. This is the source of many of the failures on the following dashboard https://open.cdash.org/viewTest.php?onlyfailed&buildid=3781713 as the mapping of cells to colors is based on gl_PrimitiveId and it seems to be restarting after 339. My code (a VTK branch) has a vertex shader and fragment shader with no geometry shader. I am requesting and getting a 3.2 core context. The same codebase on Windows using nvidia or intel drivers (non mesa) is working. Any help appreciated. If there is additional information etc that would be helpful just let me know and I can try to dig it up.
Any particular driver this happens on?
I'm not sure if I am looking up the driver correctly but a version of glxinfo I installed says OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits) OpenGL version string: 3.0 Mesa 10.3.0 but an ldd on it shows it linking against /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 I did build mesa 10.5.3 and sudo make install it so I'm not sure why glxinfo is reporting 10.3.0. ldd on my app shows linking against /usr/local/lib/libGL.so.1.2.0
(In reply to Ken Martin from comment #2) > I'm not sure if I am looking up the driver correctly but a version of > glxinfo I installed says > > OpenGL vendor string: VMware, Inc. > OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits) > OpenGL version string: 3.0 Mesa 10.3.0 > > but an ldd on it shows it linking against > > /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 > > I did build mesa 10.5.3 and sudo make install it so I'm not sure why glxinfo > is reporting 10.3.0. > > ldd on my app shows linking against /usr/local/lib/libGL.so.1.2.0 You can probably get the info by doing LD_LIBRARY_PATH=/usr/local/lib glxinfo
By the way, supplying an apitrace that demonstrates the issue would make debugging this quite useful. (https://github.com/apitrace/apitrace)
Or even better, a piglit test :-). I suspect there's an issue with the prim assembler in draw. Since from a quick look it seems like the prim assembler would always reset the prim_id it's going to inject whenever it's run, and that's going to happen per chunk (as we don't process all vertices in a draw call at once if there's too many). Probably would need to fix that somehow so it's only reset per instance. We possibly (?) handle this correctly if there's a gs.
Created attachment 115271 [details] apitrace file Here is the apitrace file
And here is the driver using the propoer LD_LIBRARY_PATH OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits) OpenGL version string: 3.0 Mesa 10.5.3 OpenGL shading language version string: 1.30 OpenGL context flags: (none) So I guess thast means llvmpipe with mesa 10.5.3
Created attachment 115274 [details] Valid Image Here is what the image should look like, the cells are colored with the red channel being gl_PrimitiveId%256 and the green channel being ((gl_PrimitiveID/256)%6)/5.0 Just did that to try to see what is happening with the primitive ID.
(In reply to Roland Scheidegger from comment #5) > Or even better, a piglit test :-). > > I suspect there's an issue with the prim assembler in draw. > Since from a quick look it seems like the prim assembler would always reset > the prim_id it's going to inject whenever it's run, and that's going to > happen per chunk (as we don't process all vertices in a draw call at once if > there's too many). Probably would need to fix that somehow so it's only > reset per instance. > We possibly (?) handle this correctly if there's a gs. (In reply to Roland Scheidegger from comment #5) > Or even better, a piglit test :-). > > I suspect there's an issue with the prim assembler in draw. > Since from a quick look it seems like the prim assembler would always reset > the prim_id it's going to inject whenever it's run, and that's going to > happen per chunk (as we don't process all vertices in a draw call at once if > there's too many). Probably would need to fix that somehow so it's only > reset per instance. > We possibly (?) handle this correctly if there's a gs. Any suggestion on a piglit test to use as a starting point? It would need OpenGL 3.2 and the basic test would be draw say 10000 triangles each covering the entire window with this fragment shader #version 150 main { // throw out the first 9999 triangles (0 to 9998) if (glPrimitiveID < 9999) { discard; } // for the last triangle create the color based on glPrimitiveId gl_FragColor = vec4(glPrimitiveId%256,glPrimitiveId/256,0.0,1.0); } Then test the color of a pixel to see if it is RGBA (15,39,0,255) or the equiv in float.
Bah how do you edit comments? Both of the above comments should be glPrimitiveId%256/255.0 etc to make sure the resulting value is in the range of 0.0 to 1.0 of course.
Well I think there's already piglit tests which test this functionality (primitive-id-no-gs and similar), but they might not hit it because they only test a couple of primitives and not that many. Not sure though if they could be extended to test larger draw calls easily. I did some very quick hack with the prim assembler (not resetting the prim id at all when it is run, which is at least as wrong but I think should work with this example) and it indeed looked quite a bit different. Still not the same as the comparison image though (circle seemed to have way more segments???)
Created attachment 115275 [details] Even More Valid Image Doh. I am working from two different source trees and I suspect I had the resolution of the sphere set differently on those two runs. Maybe this image matches your patched run.
FWIW this is what I get with nouveau on a nvc1: http://i.imgur.com/8QS20cp.png Matches your "even more valid image" attachment, I think.
(In reply to Ken Martin from comment #12) > Created attachment 115275 [details] > Even More Valid Image > > Doh. I am working from two different source trees and I suspect I had the > resolution of the sphere set differently on those two runs. Maybe this image > matches your patched run. Yeah looks like it (only the first frame though the trace redraws the same thing and then it looks different presumably because the prim id didn't get reset for the second draw...). Not sure yet how to fix it properly, those prim ids are slightly annoying because how they are created differs completely if there's a gs or not in our code. But somehow the primid really needs to happen per instance.
(In reply to Ilia Mirkin from comment #13) > FWIW this is what I get with nouveau on a nvc1: > http://i.imgur.com/8QS20cp.png > > Matches your "even more valid image" attachment, I think. Yes that matches and shows that the primitiveID is going up as it should.
Created attachment 115276 [details] New piglit test Here is a piglit test to go in piglit/tests/spec/glsl-150/execution/primitive-id-no-gs-high-count.shader_test I believe it exposes the issue.
(In reply to Ken Martin from comment #16) > Created attachment 115276 [details] > New piglit test > > Here is a piglit test to go in > > piglit/tests/spec/glsl-150/execution/primitive-id-no-gs-high-count. > shader_test > > I believe it exposes the issue. Hmm doesn't look very practical indeed. I guess those shader tests aren't really prepared for testing something like this...
Fixed by f2a7fd9943fcb7d3de3bc2b21907e0a157b88e96.
Tested and it looks good, gl_PrimitiveId is incrementing properly.
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.