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