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

[Marek Olšák]

2011/7/18 Mathias Fröhlich <Mathias.Froehlich at gmx.net>:
>
> 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.

The case you described doesn't need the DISCARD flags at all. You even
mention that all you need is the unsychronized flag and grabbing a new
buffer when needed. DISCARD is really just for stuff like
transfer_inline_write, BufferData, BufferSubData (all those imply
DISCARD), and whenever you need to do a non-blocking write-only
transfer to an existing buffer. If you *can* grab a new buffer, it's
always preferred to do so.

There is another fact which should be taken into account. Considering
that pipe_resource (or any struct derived from it) is a screen object,
which means it can be shared among multiple contexts running on
different threads, it either must not be changed during its lifetime
or any read/write accesses to it must be guarded by mutexes. Otherwise
very bad things may happen. The gpu copy ensures that pipe_resource
(or any struct derived from it) is not changed during transfers.

Marek