On Thu, 9 Jul 2020 at 13:47, Axel Davy davyaxel0@gmail.com wrote:
I have another explanation for this behaviour:
For the first DISCARD you try, the buffer backing is busy because it is doing to be used for rendering not yet finished. Thus the DISCARD does actually do something.
Then when you map for reading the buffer it flushes everything and rendering has to finish. Thus for the next DISCARD, the driver finds that the driver backing is not busy, it decides to keep it.
Definitely you should discard buffer data if the buffer is not bound. It will happen in a lot of games. A buffer not bound doesn't mean it is not used by the GPU. What you really want is to not discard when the buffer is not bound nor used in any pending rendering. That is of course much harder to detect. I would bet your application just needs the DISCARD to do nothing before the buffer is used for rendering for the first time.
Yes, what Axel said. I suspect the application is essentially depending on an optimisation to not bother discarding the buffer if we wouldn't have to wait to map it. I.e., similar to the redundant discard filtering we do a bit further down in buffer_resource_sub_resource_map(), and similar to the Vulkan discard handling we do in adapter_vk_map_bo_address(). In its current form, this patch will introduce stalls when mapping buffers that have been unbound, but are still in use by the GPU.