NVIDIA sneakily put out a little open source release recently, with a part of the NVAPI SDK now under the MIT license.
This was mentioned by the crew working on the DXVK translation layer in the VKx Discord, who sent along word to me as well. NVAPI is NVIDIA's core software development kit that allows direct access to NVIDIA GPUs and drivers on all Windows platforms.
Now, that doesn't sound interesting for Linux obviously but here's why this actually is important: in the NVAPI Open Source SDK, it directly mentions that the contained "nvapi.h" file that's now provided under the MIT license was done to enable "open source re-implementations of NVAPI for Windows emulation environments"—so the Wine and Proton compatibility layers are what they're getting at without naming them directly.
What's the issue with it then, why did this need to be done? Well, DXVK at times has to work around the NVAPI and it ends up spoofing an AMD GPU for some titles to do this, otherwise they just don't work on Linux with Wine / Proton. Speaking briefly to Philip Rebohle, creator of DXVK, they mentioned to me that there's going to be things that aren't possible to implement but it does now give them something to work with.
It's just another small piece of a much larger puzzle of getting Windows games running on Linux.
You can find the download here if interested. More info on the NVAPI here.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: aufkrawallI hope this will allow to reduce the weird performance hit by DXVK in some titles. E.g. the round achievement screen in HotS runs like ~50% faster with native D3D11 on Pascal.Not going to happen. While (some) nvapi extensions can improve performance if used correctly, expect single-digit gains at best.
Games running 50% faster on Windows isn't exactly uncommon on (especially older) Nvidia generations and is just more a result of certain aspects of Vulkan not being a great fit for the hardware, as well as D3D drivers doing black magic in the background like optimizing shaders based on application-provided parameters etc which we're not doing, and in CPU-bound cases, just overall CPU overhead which in turn is mostly caused by key aspects of the respective APIs being quite different.
AMD is more consistent because their drivers (including OpenGL fwiw, see radeonsi) end up doing more or less the same things that DXVK on top of one of their Vulkan drivers would.
And there's always a chance that your performance issues aren't related to D3D at all.
Also, this whole thing really just couldn't come at a worse point in time, I'm very busy with vkd3d at the moment, Joshua has been working on that as well, and I'm not sure if there's anyone else ready to pick it up and start working on it.
Last edited by YoRHa-2B on 13 July 2020 at 8:24 am UTC
10 Likes, Who?
aufkrawall Jul 13, 2020
Quoting: YoRHa-2BAlso, this whole thing really just couldn't come at a worse point in time, I'm very busy with vkd3d at the moment, Joshua has been working on that as well, and I'm not sure if there's anyone else ready to pick it up and start working on it.I think everyone is super happy that you guys are taking care of VKD3D. :)
Regarding HotS performance: Even with D3D11, the 1070 OC is like ~80% faster than my previous RX 570 OC in that particular scene. With DXVK, it's still 20-30%, which is pretty normal in VK apps (can be even worse). I'd blame Blizzard here for not optimizing more for AMD (or the game's crappy performance in general...).
Funny thing is that for whatever reason, DXVK helps to reduce stuttering in HotS vs. D3D11 when combining it with certain ways to cap fps. This makes me prefer DXVK over native D3D11 anyway, despite of the increased GPU demands.
Dunno why Nvidia think they'd have to throw these particular open bits over the fence at this very moment. I'd expect them to do this at least for DLSS if they cared about that share of their customers. Thanks for nothing? ;)
1 Likes, Who?
Quoting: YoRHa-2BQuoting: aufkrawallI hope this will allow to reduce the weird performance hit by DXVK in some titles. E.g. the round achievement screen in HotS runs like ~50% faster with native D3D11 on Pascal.Not going to happen. While (some) nvapi extensions can improve performance if used correctly, expect single-digit gains at best.
Games running 50% faster on Windows isn't exactly uncommon on (especially older) Nvidia generations and is just more a result of certain aspects of Vulkan not being a great fit for the hardware, as well as D3D drivers doing black magic in the background like optimizing shaders based on application-provided parameters etc which we're not doing, and in CPU-bound cases, just overall CPU overhead which in turn is mostly caused by key aspects of the respective APIs being quite different.
AMD is more consistent because their drivers (including OpenGL fwiw, see radeonsi) end up doing more or less the same things that DXVK on top of one of their Vulkan drivers would.
And there's always a chance that your performance issues aren't related to D3D at all.
Also, this whole thing really just couldn't come at a worse point in time, I'm very busy with vkd3d at the moment, Joshua has been working on that as well, and I'm not sure if there's anyone else ready to pick it up and start working on it.
Do you think it is actually feasible to turn these extension libraries into something workable within Proton at all?
My impression is that this is going to be quite difficult. On the one side AMD unfortunately messed up the versioning of their AGS SDK and on the other side the NVAPI SDK is way to big to get an alternative implementation into a state that works for all games that do use NVAPI. My guess is that it will ever work for only a small selection of games like aforementioned UE4 games. Dunno if Proton will ever get a kind of profile for games where NVAPI (or AGS) is enabled based on the title.
0 Likes
FinixFighter Jul 13, 2020
Nice to hear that! :D
0 Likes
Quoting: jensMy impression is that this is going to be quite difficult. On the one side AMD unfortunately messed up the versioning of their AGS SDK and on the other side the NVAPI SDK is way to big to get an alternative implementation into a state that works for all games that do use NVAPI. My guess is that it will ever work for only a small selection of games like aforementioned UE4 games. Dunno if Proton will ever get a kind of profile for games where NVAPI (or AGS) is enabled based on the title.Proton already has that for AGS since Wolfenstein II requires it (it uses its own dummy implementation).
I think you're right though. Games make wonky/incorrect assumptions all the time about feature support etc, and documentation for these libraries is by no means great, so it's going to be hard to make something that universally works, but as mentioned in the article, it's worth a try.
1 Likes, Who?
Patreon
PayPal
See more from me