2011/7/18 Mathias Fröhlich <mathias.froehl...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
