See example at generated_tests/spec/glsl-1.10/execution/interpolation/interpolation-none-gl_FrontColor-flat-fixed.shader_test This sets a position s.t. the clipping at +/-1 takes effect. And it works just fine - the clipped result is correct. However the color output is green instead of blue - the first vertex's color is broadcast to the new triangles rather than the last vertex's color. I traced through the code a bit, and it seems to *want* to do the right thing, but for some reason doesn't. Smooth shading works fine in this clipping scenario. With user-provided clip planes (or distances), i.e. in where the clipping stage does nothing, the color is picked correctly.
Actually I tracked it down to this little bit in clip.h: void ClipSimd(const simdscalar& vPrimMask, const simdscalar& vClipMask, PA_STATE& pa, const simdscalari& vPrimId, const simdscalari& vViewportIdx) { ... uint32_t provokingVertex = 0; if(pa.binTopology == TOP_TRIANGLE_FAN) { provokingVertex = this->state.frontendState.provokingVertex.triFan; } ///@todo: line topology for wireframe? Which is ... obviously wrong. That said, I'm not sure what the right thing is, esp in light of how the topologyProvokingVertex is selected in the FE. I leave it to the pro's.
This also affects softpipe and llvmpipe. I'm not familiar with mesa, but I think there are multiple places that do the wrong thing. For example, do_clip_tri() in src/gallium/auxiliary/draw/draw_pipe_clip.c gets passed the vertices in winding order, but it doesn't take that into account when determining provoking vertex. If this should be split off to a separate bug, then I'll do so. This causes failures in Wine's conformance test suite, since we use GL_FIRST_VERTEX_CONVENTION universally, and test flat shading with GL_TRIANGLESTRIP and some vertices slightly clipped outside of the viewport. Since our test suite is run in a virtual machine, it uses llvmpipe, and so is affected by this bug.
(In reply to Zebediah Figura from comment #2) > This also affects softpipe and llvmpipe. I'm not familiar with mesa, but I > think there are multiple places that do the wrong thing. For example, > do_clip_tri() in src/gallium/auxiliary/draw/draw_pipe_clip.c gets passed the > vertices in winding order, but it doesn't take that into account when > determining provoking vertex. > > If this should be split off to a separate bug, then I'll do so. > > This causes failures in Wine's conformance test suite, since we use > GL_FIRST_VERTEX_CONVENTION universally, and test flat shading with > GL_TRIANGLESTRIP and some vertices slightly clipped outside of the viewport. > Since our test suite is run in a virtual machine, it uses llvmpipe, and so > is affected by this bug. I suspect it's a different issue. For llvmpipe the piglit test you pointed out works just fine. (I have some suspicion for llvmpipe/softpipe it would make a difference if you use interpolation qualifier flat vs. shade model flat. See the FIXME in draw_pt_decompose.h - the order of decomposing should only be determined by flatshade_first, and not depend on if flatshade is actually active. But we need this to compensate for some bug elsewhere, apparently...)
(In reply to Roland Scheidegger from comment #3) > I suspect it's a different issue. For llvmpipe the piglit test you pointed > out works just fine. > (I have some suspicion for llvmpipe/softpipe it would make a difference if > you use interpolation qualifier flat vs. shade model flat. See the FIXME in > draw_pt_decompose.h - the order of decomposing should only be determined by > flatshade_first, and not depend on if flatshade is actually active. But we > need this to compensate for some bug elsewhere, apparently...) Yes, you're right; I see now this is a different bug. Sorry for polluting this one. I've opened bug 110451.
-- 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/189.
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.