DX12 did not get a HVV/Device Local heap for a looong time to be able to do this optimization on UMA.
It is really up to the application to do any zero-copy logic itself, just like in Vulkan.
I agree with you that such optimisation should be done on the application side. But as a lot of games wasn't done with APU on mind it could be interesting to perform it "on the fly" (if possible and that's a big if) when translating DX12 calls to VLK ones if the physical device seems to be an APU.
What exactly do you expect a driver to do here and which API usage patterns do you expect to get magically optimized?
@HansKristian-Work GPU can map CPU RAM, but it's very slow as the GPU has to get data from the PCIe link on a CPU + GPU setup and so never used on desktop configuration. As in an APU the GPU and the CPU work with the same shared memory, this feature can be used in order to make the economy of a copy command when passing buffer from CPU to GPU. It allow to reduce memory usage (there is a gain in place as the content of the buffer isn't present twice in both CPU part of the memory and GPU part and in time as the data is available immediately for the GPU instead of waiting the end of the transfer). This feature is already existing into the drivers (i'm talking here about amdgpu one as it's the only one i know) and implemented into vulkan. So buffer which are copied to VRAM and immediately deleted on host side could be transferred "as is" to the GPU without performance loss in an APU (maybe there could be others use case but it the simpliest one wich came in my mind yet)
I talk about checking the physical device earlier because doing such with a dedicated GPU on a PCIe link will be counter-productive, doing this only improve APU graphic pipeline
D3D12 apps will just use the UPLOAD heap directly and that memory is directly accessed by GPU. On desktop, we try to place it in ReBAR so apps can punch through to VRAM, but on integrated like Deck there is no meaningful difference.
If CPU and GPU want to share the memory CUSTOM heap + WRITE_BACK cache semantics work, as does EXT_external_host_memory imports via CreateHeapFromAddress.
upload heap/ReBAR are effort from the constructor in order to unify RAM an VRAM and make them usable as if it were an UMA, so for application which already use such functionality there is no room for optimization as it's already done. The idea is to force it for application which does not use them (if possible) on UMA devices such as APU. And as the upload heaps and ReBAR is relatively new for DX12 there should be a lot of application wich should beneficiate from that
"One reason to use GPU upload heaps on integrated GPUs is that you can use GPU upload heaps instead of using upload + default heaps for resources, so there’s no need to do a lot of copy operations just to put the resource in a different state. Alternatively this optimization can be done via [UMA Optimizations: CPU Accessible Textures and Standard Swizzle](https://docs.microsoft.com/en-us/windows/win32/direct3d12/default-texture-mapping)."
https://microsoft.github.io/DirectX-Specs/d3d/D3D12GPUUploadHeaps.html
The idea is to force it for application which does not use them (if possible) on UMA devices such as APU
This is meaningless on Deck. HOST_VISIBLE is always fast, and we end up trying the DEVICE_LOCAL | HOST_VISIBLE type anyways.
Alright then, thanks for your response !
Nothing extracted yet.
I confirm:
contain this feature already.
Description
As steam deck use an APU, it seam that the graphic pipeline should be different that the one used on configuration with discrete GPUs.
Justification
In an APU, the RAM and VRAM are the same, thus it is possible to transfer data from RAM to VRAM without actually copying it, leading to less stress on the northbridge and memory (RAM and VRAM). As the zero copy way of programming is performed when vulkan/openGL is used and not inside the driver itself (it's more a matter about how vulkan /openGL is used than how it's implemented), it seems that it's the job of the proton layer to do so when re-interpreting graphics library calls (by creating buffer with MEM_ALLOC_HOST_PTR for example). I wonder if this feature is taken in account in proton (and if proton does a specific graphic pipeline for APUs) or if everything is set as if it where an discrete GPU no matter the hardware it's running on? (Because using zero copy with a discrete GPU architecture is not an good option, it is only efficient with APU)
References
Different sources i could gather on the subject (mostly about openCL, but still):
https://stackoverflow.com/questions/12766578/access-path-in-zero-copy-in-opencl
http://meseec.ce.rit.edu/551-projects/spring2017/2-2.pdf
https://community.amd.com/t5/opencl/optimizing-data-transfer-with-apu-best-way-to-test-zero-copy/m-p/152658/highlight/true
https://free.eol.cn/edu_net/edudown/AMDppt/OpenCL Programming and Optimization - Part II.pdf (from page 36)
Regards