I'm not familiar enough with draw internals to tell whether your changes are
enough or not.
But I'm OK with this change as is, given that most drivers will not advertise
PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION, so only those that do
advertise need to be tested to ensure that things
On 02/07/2012 05:24 PM, Jose Fonseca wrote:
I'm not familiar enough with draw internals to tell whether your changes are
enough or not.
But I'm OK with this change as is, given that most drivers will not advertise
PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION, so only those that do
- Original Message -
On 02/07/2012 05:24 PM, Jose Fonseca wrote:
I'm not familiar enough with draw internals to tell whether your
changes are enough or not.
But I'm OK with this change as is, given that most drivers will not
advertise
Just let the hardware do it if it can and avoid drivers having to
check for the special case on each draw call.
v2: update the draw module
---
src/gallium/auxiliary/draw/draw_context.c |7 -
src/gallium/auxiliary/draw/draw_decompose_tmp.h | 26 +++---
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/
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
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
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
Just let the hardware do it if it can and avoid drivers having to
check for the special case on each draw call.
---
src/gallium/docs/source/cso/rasterizer.rst |7 ---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/drivers/i915/i915_screen.c |1 +
