dxvk-nvapi: Add to Proton

[liam-middlebrook]

Add https://github.com/jp7677/dxvk-nvapi as a submodule. dxvk-nvapi will
not be copied into Proton prefixes by default, but instead will be
controlled via the environment variable PROTON_ENABLE_NVAPI. This is
done to avoid any potential adverse effects of the nvapi DLL existing
in cases where an application may require a function that is not
implemented by dxvk-nvapi.

This new functionality can be enabled by setting the following environment
variable to a value of 1:
PROTON_ENABLE_NVAPI

Additionally the PROTON_NO_NVAPI_CLEANUP environment variable has been
added for development/debugging purposes.

This functionality is needed in order to support DLSS within Proton.

[aeikum]

Looks good. I added a fixup commit to your branch with a couple small changes. Some other thoughts:

1. What is the purpose of PROTON_NO_NVAPI_CLEANUP? I'd rather not have it if we don't need it.

2. Is there a release model for dxvk-nvapi? I prefer to use release tags for our submodules, but I understand that's not always possible.

3. We are planning to switch back to using DXVK's DXGI in the near future. If DXVK devs don't object, I might do that in the same release, which would simplify the use_dxvk_dxgi logic. In that case, I'll also be sure to disable NVAPI if we are using wined3d's DXGI.

[jp7677]

I can create a release for dxvk-nvapi if that makes things a bit more convinient.
@liam-middlebrook Could you please confirm that current master is fine for your use case? I'll do some smaller tests on my own just to be sure and if everything is fine, I'll tag and release.

[liam-middlebrook]

1. What is the purpose of PROTON_NO_NVAPI_CLEANUP? I'd rather not have it if we don't need it.

I had it in for local testing so that I could easily drop-in a custom nvapi64.dll after tweaking things around. It's not strictly necessary.

3. We are planning to switch back to using DXVK's DXGI in the near future. If DXVK devs don't object, I might do that in the same release, which would simplify the use_dxvk_dxgi logic. In that case, I'll also be sure to disable NVAPI if we are using wined3d's DXGI.

I'm fine with simplifying the use_dxvk_dxgi logic if things work out that way.

@liam-middlebrook Could you please confirm that current master is fine for your use case? I'll do some smaller tests on my own just to be sure and if everything is fine, I'll tag and release.

I'll confirm this later today and comment here once I've verified. From inspection I don't think there should be any issues with that.

[liam-middlebrook]

Another thought I had was that when PROTON_ENABLE_NVAPI is in-use there currently isn't any logic that talks to dxvk_config.dll to enable/disable the NvAPI Hack (which spoofs the vendor/device IDs). I tried looking for some prior art here so that I could plumb that option down, but wasn't able to find anything.

[aeikum]

Another thought I had was that when PROTON_ENABLE_NVAPI is in-use there currently isn't any logic that talks to dxvk_config.dll to enable/disable the NvAPI Hack (which spoofs the vendor/device IDs). I tried looking for some prior art here so that I could plumb that option down, but wasn't able to find anything.

Yeah, that's something to ask the DXVK folks how they want to handle (disable the nvapi hack if loading nvapi.dll succeeds or something). We can then duplicate that logic in Wine's DXGI.

[aeikum]

I've pushed a couple more changes. This drops the PROTON_NO_NVAPI_CLEANUP switch, and changes to prefer DXVK's DXGI by default. I'll be updating our DXVK version too, but that's not on this branch. This branch is still using jp7677/dxvk-nvapi@fcd8ce2 .

I'm planning to release this in Experimental today if no one objects.

[liam-middlebrook]

Putting this in Experimental is good with me. I'll follow up with the DXVK maintainers separately regarding the future of their nvapiHack option.

[jp7677]

I have tagged current master of dxvk-nvapi as v0.3, though Liam has the final word if the git submodule here should be updated to that version.

[liam-middlebrook]

Let's go with dxvk-nvapi v0.3

[aeikum]

v0.3 it is. Thanks!

[aeikum]

This is included in experimental-6.3-20210602 as 0503dde.