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

[Jose Fonseca]

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);
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
>