Bug 98846

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.