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

[Marek Olšák]

BTW I am in favor of adding the CAP. r300 doesn't support the
first-vertex convention for quads, but r600 does support it and it
cannot be disabled for quads only. Because of that, the provoking
vertex switch is currently part of the draw state instead of the
rasterizer state in r600g. Adding the CAP will help move it back to
the rasterizer state.

Of course, if we didn't have r600 and nv50 drivers, the CAP would be useless.

Marek

On Mon, Jan 30, 2012 at 5:59 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev