Hello @duplexsystem, dxvk-nvapi is already part of Proton, and it looks like amd_ags_x64.dll is commonly redistributed with individual games. I'm not sure what's involved on the Intel side.
To me this reads like a pre-emptive call to evaluate a potential future performance pitfall instead of a feature request. Do you know of a specific example which a Proton dev can use as a test case?
Hello @kisak-valve, dxvk-nvapi currently lacks support for 64bit Typed Atomics DirectX extensions, and many other DirectX extensions epically newer DX12 ones. The amd_ags_x64.dll shipped with games does not work correctly through proton, and needs to be replaced with one that does work on proton, Wine currently includes a stub for it see here but it currently only provides the ability to query hardware information not any DirectX extensions. dxvk-ags provides some DirectX extensions but does not have support for DX12 nor 64bit Typed Atomics at all. In addition it is not bundled with Proton as of right now. As for Intel this repo is currently used exclusively for 64 Bit Typed Atomics and, to my knowledge, lacks any, stub or not, Wine reimplementation.
As for testing the performance impact of Unreal's usage of 64 Bit Typed Atomics in Nanite, the City Sample is a tech demo designed to showcase both Lumen and Nanite and would likely show a performance discrepancy if there was any. Epically on AMD RDNA2 where AMD AGS provides a ray tracing hit token in addition to 64 Bit Typed Atomics. This can either be compiled and packed yourself or one of many unofficial prebuilt versions can be downloaded. However AMD AGS/NVAPI/IntelExtensions DirectX Extensions Support is not limited to 64 Bit Typed Atomics in Unreal Engine 5. Off the top of my head Resident Evil 2, Devil May Cry 5, and Assassin's Creed Valhalla make use of AMD AGS for some minor performance gains. Serious Sam VR makes use of AMD LiquidVR (another AMD library which provides DirectX Extensions similar to AGS) for performance gains (specifically from multiview). There is a large library of games that make use of NVAPI for performance improvements. A good way to test performance degradation is NVIDIA VR Funhouse which makes extensive use of many NVAPI DirectX Extensions. There is a large library of existing games which make use of AMD AGS or NVAPI for varying amounts of performance gain, which Proton currently doesn't replicate.
Assuming no one more experienced that me wants to try their hand at this, i'm going to try and do this myself by creating a dx extensions library with nvapi, amd ags, and intel shader extensions front ends, as a lot of the code between them can be reused. I'm going to start by "merging" dxvk-nvapi, and dxvk-ags and wine's ags stub as they each have useful components. And if this ever gets to a usable point ill then look into integrating it into proton. I have the attention span of a monkey so its highly unlikely ill finish this, but unless this issue is marked as invalid ill post progress updates here so in the likely event i don't finish this, if anyone wants to continue the work they can.
Recent versions of UE5 should support a vendor neutral path for 64bit atomics using shader model 6.6 and it's possible that there will never be a shipping game using the vendor extension path. The vkd3d-proton devs are aware of it https://github.com/HansKristian-Work/vkd3d-proton/issues/1229
I've looked through the 5.1 branch and I can't find any change on the use of vendored extensions. The only thing I could find was a unofficial, arguably hacky, patch from that github issue. Also to my knowlage this wouldn't fix the issue on DX11 as dxvk (or dx11) doesnt support shader model 6.6 (feel free to correct me if i'm wrong). In addition this doesn't allow for games to use AMD specific extensions, (nvapi-dxvk bundled with proton does a good job of this on the Nvidia side), so if the Nvidia support is deemed acceptable, this issue be switched to just non stub AGS support as that would benefit both older games (capcom engine games), current games (ac valhalla), and future games (ue5 using amds ray tracing hit token). Alternatively if all of this is a non issue ill close the issue.
Was this feature ever implemented? I heard 64-bit atomics can be used with SM 6.6 in a new build of the unreal engine, but what about the old games that make use of vendor-specific 64-bit atomics implementation?
Feature Request
I confirm:
contain this feature already.
Description
Proton currently lacks support for vendor specific DirectX extensions, causing performance degradation in some scenarios.
Justification [optional]
Up until recently this has meant missing out on, likely, minor performance optimizations on specific vendors with games that use a specific vendors DirectX extensions, usually this only happens in games that are "partnered" with a specific hardware vendor. However as of the creation of this issue, the, released, Unreal Engine 5.0 and upcoming 5.1 make use of 64bit Typed Atomics exclusively from vendor specific DirectX extensions for the poster boy Nanite geometry system. As there are no, released, games making use of Nanite, it's difficult to get exact numbers on the performance degradation from not using this extension, however Epic deemed it important enough to add the use of 64bit Typed Atomics to it's very limited use of AMD AGS/NVAPI/IntelExtensions for general use in games (i.e. not including vendor specific technologies like Nvidia Reflex or their virtual production tools), which currently seems to be limited to 64bit Typed Atomics for Nanite (AMD/Nvidia/Intel), Driver/Hardware Checks (AMD/Nvidia), and AMD's ray tracing hit token. In games that make use of Nanite it's easy to imagine gains from using 64bit Typed Atomics adding up. Epic's use of 64bit Typed Atomics is present in both DX11 and DX12 RHIs. It is unclear to me if Vulkan RHI supports using 64bit Typed Atomics, as Unreal Engine uses HLSL for all of it's sharers, via the existing DirectX Extensions or if it lacks support for using 64bit Typed Atomics. Given the second class nature of Vulkan in Unreal Engine it's likely the latter.
This makes sense for Proton as opposed to Wine as this relates to the addition/creation of additional "gaming" related libraries. Prior art here includes: dxvk-ags and dxvk-nvapi.
Risks [optional]
This could add additional technical complexity and fragmentation to Proton and related projects for little benefit.