Bug 96853 - gl_PrimitiveID is zero when rendering points of size > 1
Summary: gl_PrimitiveID is zero when rendering points of size > 1
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: Other Linux (All)
: medium major
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-07 21:10 UTC by denis.fisseler
Modified: 2019-09-18 20:25 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description denis.fisseler 2016-07-07 21:10:12 UTC
Using Mesa3d 12.1.0-devel with Ubuntu 16.04 LTS in VMware, I stumbled upon a bug regarding the contents of gl_PrimitiveID in the fragment shader.
I am using gl_PrimitiveID for color generation. When rendering a VAO as GL_POINTS and the point size set by glPointSize() is larger than 1, gl_PrimitiveID constantly had a value of 0. As soon as the point size is reduced to 1 or the type on primitive is changed to GL_TRIANGLES, gl_PrimitiveID contains correct values. For rasterized points, the value of gl_PrimitiveID in the fragment shader should equal the value of a variable(declared using "flat") set to gl_VertexID in the vertex shader. Using this workaround i was able to produce the desired values.
Comment 1 Roland Scheidegger 2016-07-08 00:15:25 UTC
I think this would be a bug in the emulation code used for large points. Specifically, a gs is used to generate two tris out of a point, which means the prim id cannot be first used in the fs, it has to be passed from gs.

Maybe something like this would fix it, but don't quote me on that...

diff --git a/src/gallium/auxiliary/util/u_simple_shaders.c b/src/gallium/auxiliary/util/u_simple_shaders.c
index 1220e18..9527d96 100644
--- a/src/gallium/auxiliary/util/u_simple_shaders.c
+++ b/src/gallium/auxiliary/util/u_simple_shaders.c
@@ -874,11 +874,14 @@ util_make_geometry_passthrough_shader(struct pipe_context *pipe,
       src[i] = ureg_src_dimension(src[i], 0);
       dst[i] = ureg_DECL_output(ureg, semantic_names[i], semantic_indexes[i]);
    }
+   src[i] = ureg_DECL_input(ureg, TGSI_SEMANTIC_PRIM_ID, 0, 0, 1);
+   dst[i] = ureg_DECL_output(ureg, TGSI_SEMANTIC_PRIM_ID, 0);
 
    /* MOV dst[i] src[i] */
    for (i = 0; i < num_attribs; i++) {
       ureg_MOV(ureg, dst[i], src[i]);
    }
+   ureg_MOV(ureg, dst[i], src[i]);
 
    /* EMIT IMM[0] */
    ureg_insn(ureg, TGSI_OPCODE_EMIT, NULL, 0, &imm, 1);
Comment 2 denis.fisseler 2016-07-08 12:30:06 UTC
This sounds plausible, thank you for shedding some light on this! The faking of large points through triangles in a GS would also explain, why some of my GS code, I use with large points and for constructing wide lines, doesn't work as expected. Unfortunately this part of the mesa code seems to have a lot of bugs, and produces crashes, no rendering output and false rendering output. The same code works flawless with ubuntu, win7, winxp on nvidia/amd/intel graphics in a non-vm environment.
Comment 3 Roland Scheidegger 2016-07-08 13:41:37 UTC
(In reply to denis.fisseler from comment #2)
> This sounds plausible, thank you for shedding some light on this! The faking
> of large points through triangles in a GS would also explain, why some of my
> GS code, I use with large points and for constructing wide lines, doesn't
> work as expected. Unfortunately this part of the mesa code seems to have a
> lot of bugs, and produces crashes, no rendering output and false rendering
> output. The same code works flawless with ubuntu, win7, winxp on
> nvidia/amd/intel graphics in a non-vm environment.

In theory if there already is a user-provided gs (which doesn't output points) then the emulation code doesn't really apply. But I don't really know this code (other than knowing this is pretty tricky stuff...).
Comment 4 Brian Paul 2016-07-08 22:53:04 UTC
I'll try to take a look at this when I get a little time...
Comment 5 denis.fisseler 2016-07-11 09:32:09 UTC
(In reply to Roland Scheidegger from comment #3) 
> In theory if there already is a user-provided gs (which doesn't output
> points) then the emulation code doesn't really apply. But I don't really
> know this code (other than knowing this is pretty tricky stuff...).

According to my testing, GS with Mesa3d show a kind of strange mixed behavior. I have a GS, that fakes wide lines by constructing screen aligned quads from lines. If I use it in VMware with Ubuntu 16.04 LTS and Mesa3d, it does not construct wide lines, but only lines of width 1. Now if I abort the GS, using a return statement right at the beginning of the main method and do not output anything, lines of width 1 are still shown in the viewport. For those lines however to be colored correctly, I have to output that color from my GS. So it seems the geometry output part of the GS is somehow overridden, while other parts of it are not.
Comment 6 Ilia Mirkin 2016-07-13 17:02:54 UTC
On a quick scan of the logic, the main issue I noticed was that using the emulated point sprites depends on info->mode (via u_reduced_prim), but instead it should depend on the output mode of the GS [if present] or DS [if present... and I know svga doesn't support that yet].
Comment 7 GitLab Migration User 2019-09-18 20:25:24 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1004.


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.