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