On 19.04.2013 14:08, Marek Olšák wrote: > That's not true. PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE does not copy > data in radeon drivers. It really does what st/mesa does - it creates > a new buffer and throws away the old one, which doesn't take any GPU > bandwidth. Doing that at a lower level should be faster in theory (+
Moreover, for VRAM buffers it also saves me the reallocation because they always use staging transfers. The only downside is if you do have to reallocate you have to check all binding points and set them dirty if they use the resource in question. I just hope that for the other multithreaded contexts (which you can't really interrupt to set dirty bits) we can assume that the user takes care of any issues ... > drivers have multiple options how to implement the discarding). > > Only PIPE_TRANSFER_DISCARD_RANGE copies data in radeon drivers, which > is not used here. > > Marek > > On Wed, Apr 17, 2013 at 8:15 PM, Eric Anholt <e...@anholt.net> wrote: >> Marek Olšák <mar...@gmail.com> writes: >> >>> The next patch makes sure _NEW_BUFFER_OBJECT is not needlessly set >>> for this code. >> This seems like a pretty dubious optimization -- on UMA systems you're >> increasing the memory bandwidth usage in the "&& data" case, and only >> trying to eliminate update_array_object_max_element, which also happens >> with _NEW_PROGRAM (I bet it's true every time that a _NEW_BUFFER_OBJECT >> was flagged, anyway). >> >> In short, for the Mesa core change, I'd like to see some actual >> performance justification on this one. > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
