[Mesa-dev] i965 GL_ARB_buffer_storage
Jose Fonseca
jfonseca at vmware.com
Tue Mar 4 07:00:53 PST 2014
----- Original Message -----
> ----- Original Message -----
> > One thing I noticed while working on this was that we only reallocate
> > buffer
> > storage for INVALIDATE_BUFFER_BIT when UNSYNCHRONIZED_BIT is unset. The
> > ARB_mbr spec says that the contents "may be discarded", not "must be
> > discarded". However, while writing the glamor code I happened to type this
> > for the wraparound case:
> >
> > glamor_priv->vb = glMapBufferRange(GL_ARRAY_BUFFER,
> > 0, size,
> > GL_MAP_WRITE_BIT |
> > GL_MAP_INVALIDATE_BUFFER_BIT
> > |
> > GL_MAP_UNSYNCHRONIZED_BIT |
> > GL_MAP_PERSISTENT_BIT |
> > GL_MAP_COHERENT_BIT);
> >
> > intending that the buffer storage get reallocated, and that we not worry
> > about
> > any synchronization after that. My code would have been broken on the i965
> > driver. I'm wondering if this is the intended behavior of the spec, or if
> > we
> > want to treat the "may" as a "must".
>
> It's a good question. And it seems a common problem [1].
>
> I think the point of "may" in the spec is that, if there are no pending draw
> commands on the buffer, then there is no point in reallocating the buffer
> storage -- reusing the existing storage could be actually faster. Hence
> "may" instead of "must". (That is, the application should make no
> assumptions that the contents will be zero'd or anything of the sort.)
>
>
> If the buffer being mapped has pending commands, then it could be safe for
> the driver to ignore GL_MAP_INVALIDATE_BUFFER_BIT, but only if it also
> ignores GL_MAP_UNSYNCHRONIZED_BIT too, i.e, the driver should sync at that
> point.
Just to be clear, IMO the ideal is for the driver never syncs, and honours GL_MAP_INVALIDATE_BUFFER_BIT and re-allocates storage if sync is about to happen. Sync is just 2nd best if the driver prefers not to honour GL_MAP_INVALIDATE_BUFFER_BIT.
Jose
More information about the mesa-dev
mailing list