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 <jfons...@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@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
