[Mesa-dev] i965 GL_ARB_buffer_storage

Jose Fonseca jfonseca at vmware.com
Tue Mar 4 06:54:40 PST 2014


----- 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.


Jose


[1] http://www.winehq.org/pipermail/wine-patches/2011-July/104376.html


More information about the mesa-dev mailing list