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

[Brian Paul]

José Fonseca wrote:
> 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.

Yeah, and edge flags are broken in a few places.  I think I'm nearly 
done fixing that too...

-Brian