On 02/27/2014 02:52 PM, Eric Anholt 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".
I don't understand. Your code here sets GL_MAP_INVALIDATE_BUFFER_BIT and GL_MAP_UNSYNCHRONIZED_BIT, which would have reallocated the storage, as you intended. Was this a mispaste - you originally lacked the GL_MAP_UNSYNCHRONIZED_BIT, were surprised, and eventually added it? I've had several branches to throw out the storage when GL_MAP_INVALIDATE_BUFFER_BIT was present, regardless of whether UNSYNCHRONIZED_BIT was set. I think it's a great idea. I just couldn't find any applications that hit that case, so I couldn't demonstrate an improvement. Of course, as Jose pointed out, there's no point in reallocating the storage if it isn't busy. --Ken
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
