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