[Mesa-dev] RFC: reworked Gallium provoking vertex code

[José Fonseca]

On Wed, 2010-05-05 at 11:34 -0700, Brian Paul wrote:
> Commit ddb0e18f6c5582d4d2cc59ffd16ad9c4639ed059 changed some of the 
> draw module code relating to provoking vertex.  The change was in the 
> right direction, but incomplete (and broke the glean clipFlat test).
> 
> The attached patch reworks the provoking vertex code and fixes the 
> regressions.
> 
> This is a bit complicated, but it builds on two principles:
> 
> 1. When the gallium driver draws a triangle, it always follows the 
> current provoking vertex convention.
> 
> 2. Whenever any per-triangle function is called in the draw pipeline, 
> it always follows the current provoking vertex convention.
> 
> Assuming those two things, the other changes build logically on top of 
> that.
> 
> Since gallium does not support first provoking vertex for quads or 
> quad strips, when we decompose those into triangles we have to obey 
> rules 1&2 above.  So, now there are separate QUAD_FIRST_PV and 
> QUAD_LAST_PV macros in the draw module's decomposition code instead of 
> one QUAD macro.
> 
> This patch fixes the softpipe driver, but not llvmpipe.  I'll do that 
> next if this looks OK w/ everyone.
> 
> I'm also updating the glean clipFlat test to do more exhaustive 
> testing of provoking vertex.

Hi Brian,

Sorry for opening Pandora's box without full grasp of the consequences.

I do agree with the principles you outlined, and the patch looks correct
to me.

I've also tested here with clipping DCT on softpipe and there are no
regressions. D3D doesn't cover quads or polygons though.

There is still a bit of old code in sp_prim_vbuf.c that's commented out
which should probably be removed.

Jose