lee/renderdoc
1
0
Fork 0
mirror of https://github.com/baldurk/renderdoc.git synced 2026-05-04 17:10:47 +00:00
Code Issues Packages Projects Releases Wiki Activity

Remove path to trust application flushes on coherent maps. Closes #2372

Browse Source 
* We used to allow applications to call vkFlushMappedMemoryRanges on coherent
  memory to manually annotate regions of memory that are changed in persistent
  maps, thus avoiding the overhead of RenderDoc needing to check for changes on
  each submit.
* Unfortunately this means that if the application calls flush wrongly then
  changes will no longer appear, even though the application was completely
  correct, if misleading, since by the spec behaviour vkFlushMappedMemoryRanges
  is a no-op on coherent memory so incorrect calls to it make no difference.
* Since applications making use of this are rare or non-existant we just remove
  the optimisation.
This commit is contained in:
baldurk
2021-09-23 17:37:26 +01:00
parent 42fcc3820d
commit b4e4fed40f
4 changed files with 2 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/behind_scenes/vulkan_support.rst
+1 -1
View File
@@ -24,7 +24,7 @@ Performance notes
Vulkan is intended as a high-performance low CPU overhead API, and RenderDoc strives to maintain that performance contract at a reasonable level. While some overhead is inevitable RenderDoc aims to have no locks on the 'hot path' of command buffer recording, minimal or no allocation, and in general to have low performance overhead while not capturing.
Some patterns of access are more or less conducive to good performance on RenderDoc, so if you are having trouble with slow capture, large memory/disk overhead or slow replay you might want to try eliminating use of persistent maps of memory from coherent heaps - you can use ``vkFlushMappedMemoryRanges`` to emulate non-coherent heaps and RenderDoc will take advantage of that, or you can use non-persistent maps.
Some patterns of access are more or less conducive to good performance on RenderDoc, so if you are having trouble with slow capture, large memory/disk overhead or slow replay you might want to try eliminating use of persistent maps of memory from coherent heaps by mapping and unmapping them around changes, or reduce the number of submits you make while you have coherent memory persistently mapped.
Likewise try to avoid making very large memory allocations in the range of 1GB and above. By its nature RenderDoc must save one or more copies of memory allocations to enable proper capture, so having allocations limited to only a few 100s of megabytes can help gain granularity of management and limit the memory overhead RenderDoc adds. There may be optimisation of this in future on RenderDoc's side but there are no easy guarantees.