NVIDIA open sourced part of NVAPI SDK to aid 'Windows emulation environments'

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.

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)

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.

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

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

A small step for Nvidia but a big step for the implementation under Wine / Proton!

Good news. It’s never too late to become FOSS friendly.

Spoiler, click me

unless you’re Microsoft.

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.

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.

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.

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

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? ;)

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.

Nice to hear that! :D

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.

Thanks for the additional info!