[Mesa-dev] i965 GL_ARB_buffer_storage

Jose Fonseca jfonseca at vmware.com
Tue Mar 4 07:41:11 PST 2014


I agree that apps that only write to a buffer shouldn't use both MAP_UNSYNCHRONIZED and MAP_INVALIDATE_BUFFER_BIT, if that's your point.  Apps should stick so a single strategy.  But it seems a common pitfall.

Note that MAP_INVALIDATE_*_BIT purpose is not just avoid synchronization. They also avoid copying data from GPU to CPU accessible memory for buffers that were previously written by the GPU, or for write-only buffers which reside in non-CPU-accessible GPU memory.  In fact GL_MAP_INVALIDATE_RANGE_BIT has nothing to do with synchronization at all -- it's more like "WRITE-ONLY" flag.

Jose

----- Original Message -----
> In my opinion, MAP_UNSYNCHRONIZED says that you don't have to sync,
> which makes MAP_INVALIDATE_* useless, because the invalidate flags are
> only useful for avoiding synchronization and you already know you
> don't have to do it.
> 
> Marek
> 
> On Thu, Feb 27, 2014 at 11:52 PM, Eric Anholt <eric at anholt.net> wrote:
> > 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".
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=Wh4R%2Bsr%2BRNuNltGaNWrb8ry%2F5tmSBePKlh6ZRzfxv%2FQ%3D%0A&s=41ea8aa8392e49b1e1288fcb745f45451785da17af9341393d4e07db41ed1161
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=Wh4R%2Bsr%2BRNuNltGaNWrb8ry%2F5tmSBePKlh6ZRzfxv%2FQ%3D%0A&s=41ea8aa8392e49b1e1288fcb745f45451785da17af9341393d4e07db41ed1161
> 


More information about the mesa-dev mailing list