[Mesa-dev] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION

[Jose Fonseca]

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