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

[Christoph Bumiller]

On 31.01.2012 09:49, Jose Fonseca wrote:
> I don't oppose adding the cap.
>
> But I think that the story for draw module should be figured out, as at least nv50/nvc0 drivers will advertise PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION = 1 and are using the draw module:
>
> $ git grep '\<draw_create\>' src/gallium/drivers/
> src/gallium/drivers/i915/i915_context.c:   i915->draw = draw_create(&i915->base);
> src/gallium/drivers/nv50/nv50_context.c:   nv50->draw = draw_create(pipe);
> src/gallium/drivers/nvc0/nvc0_context.c:   nvc0->draw = draw_create(pipe);

Those have been there since forever and it's not actually used or
needed, I'll happily remove it for nv50 and nvc0.

So in practice the draw module should never encounter a driver that
reports 'yes' for the cap; I'll add the assertion.

> src/gallium/drivers/nvfx/nvfx_context.c:        nvfx->draw = draw_create(&nvfx->pipe);
> src/gallium/drivers/r300/r300_context.c:        r300->draw = draw_create(&r300->context);
> src/gallium/drivers/softpipe/sp_context.c:      softpipe->draw = draw_create(&softpipe->pipe);
> src/gallium/drivers/svga/svga_swtnl_draw.c:   svga->swtnl.draw = draw_create(&svga->pipe);
>
> Either:
> - nv50/nvc0 continue to advertise PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION = 0
> - nv50/nvc0 stop using draw module (at least for things that use software vertex processing or depend on flatshading)
> - update draw module to respect PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION (as it does for triangles, but still a bit of work)
> - wait for draw module to start using geometry shaders (where available) for its workarounds, where stuff like provoking vertex can be easily accommodated  I think
>
> Jose
>
> ----- Original Message -----
>> 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