On 08/12/2010 07:37 AM, Keith Whitwell wrote:
On Thu, 2010-08-12 at 06:28 -0700, Brian Paul wrote:
On 08/12/2010 07:16 AM, Keith Whitwell wrote:
On Thu, 2010-08-12 at 06:08 -0700, Brian Paul wrote:
On 08/11/2010 09:40 PM, Luca Barbieri wrote:
[Apparently bri...@kemper.freedesktop.org is forwarded to
brian.p...@tungstengraphics.com, which is no longer valid.]
I'd suggest to put it in struct pipe_index_buffer.
The argument is that the index buffer needs to be prepared
specifically for the primitive restart enable setting:
1. If the index buffer has no restart indices, using primitive restart
will have no effect
2. If the index buffer has restart indices, not using primitive
restart will cause out-of-bounds accesses or weird rendering results
Also, the index size is there too, so there is no question of what
happens if the primitive restart index doesn't fit in the index size.
Currently the Mesa state tracker binds the index buffer for every draw
call, and thus would be unaffected (but it should stop doing that).
The thing is, primitive restart also applies to non-indexed
primitives. It would be a little weird to set index buffer state for
glDrawArrays calls.
Wow, that's a pretty wierd case. So if you set the primitive restart
value to 32 then draw_arrays(TRISTRIP, 0, 64), you'll get two strips??
Yup. If one implements glDrawArrays() and glDrawElements() in terms
of glArrayElement() it kind of makes sense, but it's not too useful.
It would have been more useful for glDrawArrays() if the restart index
were periodic. Then the primitive would be restarted after every N
vertices, rather than just one restart at i==N.
This is really wierd, and afaik peculiar to GL. It's also really easy
to implement in the mesa state-tracker, just by checking for this state
and splitting such primitives once.
I think this is really something I'd prefer to keep out of gallium - I
don't see any performance benefit of passing it down to the drivers, and
I have doubts about whether people will bother implementing it...
Yeah, I was just thinking the same thing.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
