[Mesa-dev] Mesa (primitive-restart): 682 new commits

[Keith Whitwell]

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 brianp at kemper.freedesktop.org is forwarded to
> >>> brian.paul at 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...

Keith