The Steam Deck is not a UMA device from a Vulkan point of view, so it's rather hard for us to really detect this without hard-coding it specifically for the Deck. The device reports itself as having 6GB of dedicated VRAM.
I'm also not entirely sure what kind of implications reporting an UMA device has on D3D12 heap creation rules, we might be forced into code paths that may be suboptimal on a driver level.
It should also be noted that we cannot support WriteToSubresource / ReadFromSubresource for images in a performant manner since Vulkan currently has no such functionality. The current implementation uses images with LINEAR tiling (which are slow), we're planning to rewrite this using a GPU submission (which will make readbacks stall until the GPU has completed its work).
As for ReBAR, it's rather unfortunate that D3D12 has no way to explicitly make use of that (Vulkan does). The NVAPI extension obviously won't work on the Deck out of the box, however we could wire it up and enable that code path once your application actually ships on the Proton side.
It's great to hear you're open to ReBAR support - I only mentioned it as a reference point, I was actually considering experimenting with adding an IVKD3DDevice interface that I can get via QueryInterface on the D3D12 device and then using that to create custom heaps. Would this be technically possible? I can understand if it's not desired ofc given the project scope and priorities.
Images, even with UMA, are tricky since swizzling / tiling formats are hardware specific, but the use case for UMA that ReBAR doesn't cover is decompression of buffer data used for rendering. If reading buffers from upload heaps during rendering is free (i.e. doesn't incur PCIe traffic) on Deck then I should be good to go if I can somehow reliably detect when I'm running specifically on Deck.
I was actually considering experimenting with adding an IVKD3DDevice interface that I can get via QueryInterface on the D3D12 device and then using that to create custom heaps. Would this be technically possible?
We already have an extension interface, which is currently used by Proton's nvapi implementation to enable DLSS support: https://github.com/HansKristian-Work/vkd3d-proton/blob/master/include/vkd3d_device_vkd3d_ext.idl
Extending this by adding a ID3D12DeviceExt1 should be easy enough, actually implementing support for HVV allocations is going to be somewhat tricky though since we already have a heuristic in place to allow HVV allocations for UPLOAD heaps, so any interactions there will need to be considered.
It should be theoretically possible to expose an extended CreateHeap that does ReBAR as:
There is this PR that would allow us to toggle rebar on a per-allocation basis https://github.com/HansKristian-Work/vkd3d-proton/pull/1092. However, going down the "vendor hack extension interfaces" is murky.
Reporting UMA would indeed be weird since Steam Deck has a memory type layout that looks more like a dedicated GPU, even if device local vs non-local is somewhat trivial (I believe?).
It should also be noted that we cannot support WriteToSubresource / ReadFromSubresource for images in a performant manner since Vulkan currently has no such functionality. The current implementation uses images with LINEAR tiling (which are slow), we're planning to rewrite this using a GPU submission (which will make readbacks stall until the GPU has completed its work).
Indeed, this is a good reason why exposing UMA might be problematic if it tricks apps into going down these paths.
The Steam API has a way to query if you're running on Deck, so it would make sense to do that I think.
It should probably be easy to expose the VkPhysicalDeviceType as INTEGRATED or DEDICATED. I believe APUs should report as INTEGRATED, and that might be a better hint when to skip staging buffers or not.
It should also be noted that we cannot support WriteToSubresource / ReadFromSubresource for images in a performant manner since Vulkan currently has no such functionality. [...] We're planning to rewrite this using a GPU submission (which will make readbacks stall until the GPU has completed its work).
A VK extension for this sort of behaviour is long overdue, would probably be better for us to focus on something like that instead of rewriting this to be still crap.
@Joshua-Ashton games are broken right now due to this so we need to deal with this anyway.
Thanks for the replies everyone - this answers all my questions about Steam Deck support, looks like there won't be any issues for my implementation. Feel free to close this bug unless you'd like to use it for feature tracking.
I think it's fine to close this as there is no concrete action to be taken here I think. If there is one later, feel free to open a new issue.
I'm working on a project planning to support Steam Deck as a first-class problem, and I've noticed a missing optimization opportunity:
Currently, Steam Deck reports the UMA field of D3D12_FEATURE_ARCHITECTURE's D3D12_FEATURE_DATA_ARCHITECTURE struct as FALSE, and so the engine fails to apply the relevant optimizations.