PCSX2
GS/DX12: Use aliasing resources for feedback
Description of Changes
Use aliased resources to bind a single texture as both a shader resource and render target, and use barriers instead of copies.
Rationale behind Changes
Copies are slow on DX12, barriers are faster (seemingly even on AMD).
Aliasing resources like this, as far as I can tell, is valid under the Data inheritance rules. Side note: the validation the debug device does is noticeably less strict then documentation.
This requires Resource Heap tier 1, but that appears to be mandatory for DX12.
The Need For Speed Carbon dump goes from 1697 down to 3 copies (but gains 1695 barriers).
I've done a dump run during development, there are a lot of changed dumps and I've not looked at all of them in detail, but here are a few hand picked examples that appear improved.
Deus Ex In Game
DX12 Master
DX12 PR
Okage - Shadow King
DX12 Master
DX12 PR
Suggested Testing Steps
Test the DX12 backend on AMD and Nvidia
Do dump runs and properly compare them.
Did you use AI to help find, test, or implement this issue or feature?
No
This is great, I didn’t realize feedback was possible in DX12 in this way. Do you think the same approach would work for feedback loops with a DSV as well?
This is great, I didn’t realize feedback was possible in DX12 in this way. Do you think the same approach would work for feedback loops with a DSV as well?
According to the spec, depth/stencil resources aren't compatible with the simultaneous access flag, so I don't think there is a spec legal way for DSV.
That being said, I've found that hardware is significantly less strict then the spec. if you are willing to ignore the spec, you may be able to run without the simultaneous access or ~~(as is the case with this PR's AMD hackfix)~~ use the same resource as both the SRV and DSV. If any of those methods work then they need to be verified on all relevant HW.
The problem you face ignoring the spec, is that you're then dependent on the lenience of the implementations, so your chance of something breaking goes up dramatically.
@TheLastRar Got it, thanks for the clarification. Thankfully DSV feedback is much less needed than color feedback, so that makes sense.
@refractionpcsx2 Agreed. Probably safest to stick to the spec until/unless it becomes standardized in an extension or similar.
If we want to stay in spec then we could fallback to old copy method for rdna2. We could just detect if gpu supports feature level 12.2 or higher then prefer old method, drawback is rdna3 and 4 will also be included but at least older will work and we default to Vulkan anyway. Maybe if/when amd fixes the issue we can remove the fallback.
Edit: Jordan suggested we could just cherry pick rdna2 like this https://github.com/RPCS3/rpcs3/blob/3f6529fecbacdf90aa556ae0fd39b478ae28c27f/rpcs3/Emu/RSX/VK/vkutils/chip_class.cpp#L22
That sounds like a good idea for future work, as long as it's guaranteed to work with all supported hardware.
I've replaced the AMD hack with the original copy method
I've also now checking the device ID to match known RDNA1/2 hardware, allowing other AMD generations to use the new method.
The biggest thing I notice is the clouds in Deus Ex on this PR they look worse to me? Not really sure how to explain it but look at the comparison you put Master v.s. PR for Deus Ex. Unless that's the artists intent? I can't really tell based on footage on real hardware.
The biggest thing I notice is the clouds in Deus Ex on this PR they look worse to me? Not really sure how to explain it but look at the comparison you put Master v.s. PR for Deus Ex. Unless that's the artists intent? I can't really tell based on footage on real hardware.
Of the pictures in the op, the PR picture better matched SW iirc
