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.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
16 comments
redneckdrow Jul 10, 2020
B-b-b-but WINE Is Not an Emulator! 
Good Lord, I hate recursive acronyms, don't you? But in the strictest sense, WINE is more of a compatibility layer; the difference between the two for an end-user is mostly splitting cat hairs.
Good Lord, I hate recursive acronyms, don't you? But in the strictest sense, WINE is more of a compatibility layer; the difference between the two for an end-user is mostly splitting cat hairs.
2 Likes, Who?
A few of these APIs are also used by wine-staging, as there's a bunch of features in Windows games that you cannot support without them. (PhysX in Borderlands 2 will refuse to run, for example)
1 Likes, Who?
Everytime you think they will never properly support anything open source they do.
Mostly when they don't care. When they do, good luck waiting for them to open anything.
4 Likes, Who?
TheRiddick Jul 11, 2020
This is also something that is probably required to get RTX features available under Proton/Wine
Last edited by TheRiddick on 11 July 2020 at 4:12 am UTC
Last edited by TheRiddick on 11 July 2020 at 4:12 am UTC
0 Likes
NVidia still suprises me from time to time o.O
Everytime you think they will never properly support anything open source they do.
Once PhysX was open sourced, their contribution to the Vulkan Ray tracing extensions and now NVAPI o.O What next their entire driver or at least proper support for Nouveau? :D
Strictly speaking they haven't open sourced NVAPI, but instead the interfaces so that NVAPI can be re-implemented within wine. I mean it's still nice, but it really is the bare minimum.
Well, this is more or less the same that AMD is doing for AMD AGS. The AGS SDK contains the headers and libraries to link against, see https://github.com/GPUOpen-LibrariesAndSDKs/AGS_SDK
So yeah, it is not making NVAPI Open Source, but still the standard way how these kind of SDK's are offered imho.
Having the headers officially available makes it much easier to provide "alternative" implementation. For AMD AGS there is already https://github.com/doitsujin/dxvk-ags which maps the interesting AGS methods to DXVK.
I've tried a bit in the past to apply this to NVAPI and succeeded for one method. Having the headers now makes part of it much less of a Google try-and-error approach. For the curious: https://github.com/jp7677/dxvk-nvapi
Note that I do have a programming background, but not in C or C++. I'm also barely familiar with the graphics domain. I know how to spell "shader" and have a rough picture how to position the different 3D API's, but that's it ;). This repository is really just intelligent copy/paste from DXVK-AGS and several other sources, so all credits should mostly go there. It's also quite a hassle to set this up for minimal gain.
Last edited by jens on 11 July 2020 at 1:42 pm UTC
5 Likes, Who?
A small step for Nvidia but a big step for the implementation under Wine / Proton!
1 Likes, Who?
appetrosyan Jul 11, 2020
Good news. It’s never too late to become FOSS friendly.
Spoiler, click me
unless you’re Microsoft.
1 Likes, Who?
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.
0 Likes
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.No, I spoke to a few people to confirm before publishing. Including NVIDIA.
4 Likes, Who?
aufkrawall Jul 12, 2020
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.
0 Likes
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.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
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.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?
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.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
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.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