Bug 90130 - gl_PrimitiveId seems to reset at 340
Summary: gl_PrimitiveId seems to reset at 340
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: 10.5
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-21 22:07 UTC by Ken Martin
Modified: 2015-04-29 14:02 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
apitrace file (148.86 KB, text/plain)
2015-04-22 13:50 UTC, Ken Martin
Details
Valid Image (11.44 KB, image/jpeg)
2015-04-22 14:49 UTC, Ken Martin
Details
Even More Valid Image (14.53 KB, image/jpeg)
2015-04-22 16:17 UTC, Ken Martin
Details
New piglit test (205.73 KB, text/plain)
2015-04-22 18:00 UTC, Ken Martin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Martin 2015-04-21 22:07:51 UTC
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.
Comment 1 Ilia Mirkin 2015-04-21 22:31:02 UTC
Any particular driver this happens on?
Comment 2 Ken Martin 2015-04-21 22:54:16 UTC
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
Comment 3 Ilia Mirkin 2015-04-21 22:56:05 UTC
(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
Comment 4 Ilia Mirkin 2015-04-21 22:57:29 UTC
By the way, supplying an apitrace that demonstrates the issue would make debugging this quite useful. (https://github.com/apitrace/apitrace)
Comment 5 Roland Scheidegger 2015-04-22 04:05:59 UTC
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.
Comment 6 Ken Martin 2015-04-22 13:50:53 UTC
Created attachment 115271 [details]
apitrace file

Here is the apitrace file
Comment 7 Ken Martin 2015-04-22 13:53:18 UTC
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
Comment 8 Ken Martin 2015-04-22 14:49:09 UTC
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.
Comment 9 Ken Martin 2015-04-22 15:42:31 UTC
(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.
Comment 10 Ken Martin 2015-04-22 15:45:00 UTC
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.
Comment 11 Roland Scheidegger 2015-04-22 16:01:13 UTC
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???)
Comment 12 Ken Martin 2015-04-22 16:17:20 UTC
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.
Comment 13 Ilia Mirkin 2015-04-22 16:41:56 UTC
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.
Comment 14 Roland Scheidegger 2015-04-22 16:47:32 UTC
(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.
Comment 15 Ken Martin 2015-04-22 17:02:58 UTC
(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.
Comment 16 Ken Martin 2015-04-22 18:00:13 UTC
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.
Comment 17 Roland Scheidegger 2015-04-22 18:10:53 UTC
(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...
Comment 18 Roland Scheidegger 2015-04-23 19:31:25 UTC
Fixed by f2a7fd9943fcb7d3de3bc2b21907e0a157b88e96.
Comment 19 Ken Martin 2015-04-29 14:02:19 UTC
Tested and it looks good, gl_PrimitiveId is incrementing properly.


bug/show.html.tmpl processed on Feb 24, 2017 at 03:42:45.
(provided by the Example extension).