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