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 > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
