- It is possible to lose data when uploading since the result of map_dma can change types and handles.
- Consider sync-on-exit for inherited spans
Not a problem when using passthrough DMA, but this extension does not work properly on NVIDIA + windows
- While the vulkan spec explicitly allows destroying mapped blocks, GPUOpen vma_alloc does not.
- Strangely, this issue does not afflict linux users, only windows.
- This reverts commit dbcf1b5a03bfef18f404aa6827515af319abd744.
- Avoid unmapping buffers used for GPU upload/download. It is very slow
on some platforms.
- Without async streaming this option can introduce artifacts.
The correct fix for it is to use async streaming which allows the GPU to process texture data in parallel with rendering.
Without streaming enabled the GPU can sometimes pull stale data via DMA when rendering and find the CPU has modified it.
Some DMA block entries are stubs whose parents are DMA_block_EXT
entries.
Performing load() in this case becomes a memcpy(address,
same_address_again, length) which wastes performance and introduces
bugs.
- The driver seems to cache page mapping as long as allocation has not been removed
- This is undesirable as we cannot stop the emulator to remove stale allocations every time a page is unmapped
- It is not possible to emulate passthrough memory cleanly, and we don't need to
A stupid race condition appears when trying to synchronize DMA blocks with memory inheritance.
Since the usage pattern is to acquire a range and then load or write+flush, this new data is going to be..
overwritten by the commandbuffer execution sequence later. Acquiring a scratch buffer to hold CPU content during the transition is not worth the effort..
as the data will be destroyed anyway during the transfer process immediately afterwards.
Fixes data corruption when moving data around using the emulated DMA passthrough
