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