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);

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

I'll try to take a look at this when I get a little time...

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

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

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