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

[Keith Whitwell]

Brian,

My understanding is that gallium has chosen to simplfy itself slightly
and treat quad rasterization as always following GL flatshading
conventions.  Does/could your change follow that convention?

Keith

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