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

[Keith Whitwell]

On Wed, 2010-05-05 at 20:12 +0100, Keith Whitwell wrote:
> 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?


Ugh, I couldn't tell from reading the patch, but you've explained it in
your comments... never mind...

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