Note that unless the draw module is updated to take PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION == 1 in consideration this change will cause regressions for drivers that fallback to draw module for doing things like clipping, unfilled mode, etc w/ flat shadding. Can this happen in practice? If yes, then I'm not sure if this is worth the trouble. If no, then please add an assert(PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION == 0) somewhere in draw module to catch such mismatch in the future.
For the record, there was a discussion on this when GL_EXT_provoking_vertex support was added to gallium: http://old.nabble.com/GL_EXT_provoking_vertex-and-GL_ARB_map_buffer_range-td23955481.html Jose > Keith Whitwell wrote: > > Brian Paul wrote: > > > I've been working on these two extensions in my spare time. > > > > > > Each is on a temporary/feature branch in git: > > > ext-provoking-vertex > > > and arb_map_buffer_range > > > > > > Both are implemented for swrast and gallium. > > > > > > If you're interested in either or both take a look at the > > > branches and > > > let me know if there's any concerns. > > > > > > I'll merge to master in a few days otherwise. > > > > I should mention a few open issues with GL_EXT_provoking_vertex: > > > > 1. provoking vertex for lines isn't totally working yet for > > gallium/softpipe > > > > 2. Should there be a gallium PIPE_CAP query to determine if the > > gallium driver supports first-provoking-vertex, or should all > > drivers > > be expected to support it? I'm assuming the later at this point. > Correct. Hardware that doesn't support first-vertex wouldn't support > D3D -- there isn't much of that about... Typically we have to jump on > hardware to make it support GL's provoking vertex. > > 3. The state tracker assumes that all gallium drivers support > > first-provoking-vertex for quads and quad strips too. This is > > actually an optional feature in the GL_EXT_provoking_vertex spec. > > Another PIPE_CAP query may be needed for that. > There's probably no use-case for it -- the purpose of the extension > is > to match DX9's flatshading behaviour, but DX doesn't have QUAD > primitives, so there is nothing to match... > >From my point of view we could pick any one of: > - all drivers are required to implement first-pv quads > - all drivers are required not to > - drivers can ignore first-pv for quad primitives, behaviour > undefined > I don't think it's worth adding a query/cap-bit for something like > this > (which no-one will use) - let's just pick a behaviour and make it > universal. > Keith _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
