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

[Mathias Fröhlich]

Hi,

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 
ac8fdbc1c723afb19eeaba5457ba78d0bf33b8d4.

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.

Greetings

Mathias