[Mesa-dev] [PATCH 2/2] st/mesa: Handle GL_MAP_INVALIDATE_BUFFER_BIT in st_bufferobj_map_range().

Mathias Fröhlich Mathias.Froehlich at gmx.net
Mon Jul 18 11:34:25 PDT 2011


On Monday, July 18, 2011 18:28:26 Marek Olšák wrote:
> We can't do try-map + create + map + dereference internally in a
> driver. Creating a new buffer and replacing a pointer to the old one
> may lead to the following issue. If a buffer pointer is replaced, it
> doesn't necessarily update all the states the buffer is set in in all
> existing contexts. Such states and contexts would still use the old
> buffer and wouldn't see the change until the old buffer is unbound.
Sadly yes.

> I think the only correct way to implement the DISCARD flags in drivers
> is through a temporary (staging) resource and doing an on-gpu copy to
> the original one (i.e. what we do for texture transfers in rX00g).
Which is a bit heavyweight I think.
At least for the PIPE_DISCARD_WHOLE_RESOURCE case.

The main use case I think of is buffer object streaming with possibly *huge* 
buffer object data. You would do map/unmap pairs with the unsyncronized flag . 
Once your buffer has filled up, you need to detach from the old one, just 
leaving the old one around until it is no longer used. An extra copy should 
not be required for this case.

I hoped to find some time to implement something with atomic generation counts.  
So having a atomic buffer object change counter in some struct that is shared 
across contexts and one counter in each context that is used to revalidate the 
buffer objects for this case.

We got something similar than that, for revalidating render buffers with 

I am not exactly sure if I miss something, and I did not find the time to try 
out myself. But may be this thought helps avoiding may be needless copying?

For the PIPE_DISCARD_RESOURCE flag, that operates only on a subset of the buffer 
objects data, the staging buffer object might be the way to go.



More information about the mesa-dev mailing list