Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Flattr, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

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.
46 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
19 comments
Page: «2/2
  Go to:

DMJC 11 Jul
Sure this isn't aimed more at getting NVIDIA GPU emulation working in Virtual machines such as Qemu/KVM/VMWare? VMWare uses WINE's DirectX implementation to support DirectX.
Liam Dawe 12 Jul
Quoting: DMJCSure this isn't aimed more at getting NVIDIA GPU emulation working in Virtual machines such as Qemu/KVM/VMWare? VMWare uses WINE's DirectX implementation to support DirectX.
No, I spoke to a few people to confirm before publishing. Including NVIDIA.
aufkrawall 12 Jul
I 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.
YoRHa-2B 13 Jul
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
aufkrawall 13 Jul
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? ;)
jens 13 Jul
View PC info
  • Supporter
Quoting: YoRHa-2B
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.

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.
Nice to hear that! :D
YoRHa-2B 14 Jul
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.
jens 14 Jul
View PC info
  • Supporter
Thanks for the additional info!
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.