On older versions (like 2.4), NVR relied on RESZ being available on Nvidia cards with DXVK for the resolves. I assume the change which limited vendor hacks to only the original vendors broke this.

That is correct, RESZ is only available on AMD natively and we've recently seen there are games which pick vendor paths based on this... so essentially this hasn't been "broken" recently, it was fixed.

The simplest solution that comes to mind would be a configuration option to let user enable back vendor hacks across all vendors.

Intel and other exotic mobile vendors already default to reporting AMD for d3d8/9, so the problem is only Nvidia specific and can be worked around with d3d9.hideNvidiaGpu = True. This will get you RESZ back by reporting AMD, which is the only accurate way to go about it.

P.S.: The "nvapi" path might have been fixed on master, or may be fixed by one of the pending PRs, so the above might not be necessary in the end. Took a closer look at the code you've linked and basically NvAPI_D3D9_StretchRectEx is unimplemented in dxvk-nvapi (nothing broke recently, it's always been like this, but the game was stuck on the RESZ/AMD path), so please use the above workaround on Nvidia.

Thanks for the response. I however am doubtful whether going the way of hiding Nvidia is correct.

In terms of the game, as far as I understand the main difference is a different shader path.

In terms of driver hacks, this can mean that if any Nvidia specific driver hack is used it will suddenly stop functioning (I'm not 100% certain about the presence of any at the moment).

Already got a report from someone who tested it early that says it does not in fact help. Edit: From the report it seems the game starts to get confused and tries to detect hardware again on launch.

Would it be hard to implement a new configuration option purely for controlling which driver hacks are exposed (as in all or just those for the current vendor)?

Already got a report from someone who tested it early that says it does not in fact help.

That is impossible, because d3d9.hideNvidiaGpu = True would get on the path you were taking before dxvk 2.6.2. Note that we are fully simulating the capabilities of an AMD GPU and that is handled properly even on Nvidia hardware. As I noted before, this is already done by default on Intel GPUs and mobile GPUs and works without issue.

Could be perhaps due to misspelling of the option - it is case sensitive, so "d3d9.hideNvidiaGPU = True" will not be picked up correctly.

Would it be hard to implement a new configuration option purely for controlling which driver hacks are exposed (as in all or just those for the current vendor)?

It would not be hard, but a) why would we simulate a situation that doesn't exist on real hardware? b) the above hide logic already achieves what you need here.

Edit: From the report it seems the game starts to get confused and tries to detect hardware again on launch.

That is to be expected because it will act and be detected as a GPU change. Once the game "reacquaints" itself with the new situation it should work just as usual, as long as you keep using the option. FYI it should detect the GPU as a Radeon 6700 XT.

A log should tell whether the config is picked up correctly.

Hello, I'm the one who tried the solution this morning. I copy and pasted d3d9.hideNvidiaGpu = True directly into the dxvk config so it's not a capitalization issue. I'm on a 4070 Super with the latest Nvidia drivers.

When you go to launch the game through MO2 the FNV launcher opens instead of launching the game. As soon as I remove d3d9.hideNvidiaGpu = True from the dxvk config I can launch the game through MO2 normally.

From my experience, FNV launcher only normally opens this way on a fresh install when the game needs to detect what hardware you have to set graphics settings which is what lead me to believe the game is trying to detect what hardware is being used since d3d9.hideNvidiaGpu = True seems to imply that it's masking the nvidia hardware. I am no expert however and making assumptions.

From my experience, FNV launcher only normally opens this way on a fresh install when the game needs to detect what hardware you have to set graphics settings which is what lead me to believe the game is trying to detect what hardware is being used since d3d9.hideNvidiaGpu = True seems to imply that it's masking the nvidia hardware.

I am not familiar with how this works in the game, but that does not surprise me, because we are essentially reporting a different GPU (AMD Radeon 6700 XT), which has RESZ support and all the frills of any other real life AMD GPU.

I would assume that if you go along with whatever setup/redetection steps the game requires, it should work as it would if you had an AMD GPU slotted in your system.

I will have to dig into this more when I get home, however when I tried this morning it looked like the game was still showing my 4070 Super as the GPU. I will have to see if it has a AMD Radeon 6700 XT as a selectable GPU.

It would not be hard, but a) why would we simulate a situation that doesn't exist on real hardware? b) the above hide logic already achieves what you need here.

I understand that DXVK is primarily trying to simulate real hardware and it doesn't really concern itself with modding (as evident here) - that is completely fine by me.

However, consider the situation that happened. You have a game (FNV in this) case with a mod (NVR) that used a certain path with DXVK for years by this point. A new version of DXVK releases that breaks the functionality - yes, NVR depends on a vendor hack that would not make any sense on an Nvidia GPU without DXVK - but that was remedied with Nvapi. Which however also doesn't work under DXVK.

So now we have an interesting conundrum. On one hand, the philosophy of DXVK is to adhere to real hardware and real APIs as much as possible (which means getting rid of nonsensical vendor hacks, sure). On the other, Nvapi doesn't work.

d3d9.hideNvidiaGpu = True while this could work in theory, it could have other consequences if any Nvidia specific driver hacks are used or if the game does something I am not familiar with based on the vendor.

In my mind, offering a simple configuration option for disabling the vendor hack check, especially if it wouldn't mean large scale changes, is the easiest solution. While yes, it goes against the philosophy, it also makes sure that games using old mods can still work with new DXVK versions. And it means Nvapi can stay untouched on DXVK side.

d3d9.hideNvidiaGpu = True while this could work in theory, it could have other consequences if any Nvidia specific driver hacks are used or if the game does something I am not familiar with based on the vendor.

What I'm trying to convey is that this assumption is wrong. To the application (game/mod in this case) it will appear as it is working with real AMD hardware and we are fully handling that correctly in the backend. So there would be no need to worry about "Nvidia specific hacks", since dxvk also plays the role of the driver by re-implementing d3d8/9 onto Vulkan.

There are no "other consequences", this has been widely tested and confirmed to work correctly. We are already using the option in other situations where things get into nvapi territory and cause issues, both in d3d9 and d3d11.

I understand this is a bit of a nuissance, but not having access to RESZ on Nvidia is standard behavior. Relying on that has proved to not be a good idea, since now we've fixed that particular bug/oversight. As to the situation with nvapi & dxvk, that has always been a bit of a mine field, which is one of the reasons why we have the GPU hiding logic in place.

In any case, long story short I'm quite confident d3d9.hideNvidiaGpu = True will fix things for you, but it might cause the game to be silly and reset graphical settings / detect the GPU. Sorry, but I don't think reporting things improperly just because of this one game/mod makes any sense. They're called vendor hacks because they're specific to certain vendors, after all.

I've looked at what the unmodded game does, since I wasn't too familiar with it. If you start FalloutNVLauncher.exe with d3d9.hideNvidiaGpu = True, it will show as such:

If you then launch the main game exe, also using d3d9.hideNvidiaGpu = True, it picks it up just fine. Note that I'm also using a GeForce RTX 4070 as my actual hardware.

Can't comment for the mod, but since the base game works fine, I'd expect it to be fine also?

I will have to test after work.

You can try this build based on @Blisto91 's PR: https://github.com/doitsujin/dxvk/actions/runs/16839870712/artifacts/3723183973 . It will cause a GPU redetection, but should solve the issue by making RESZ available again.

I have been testing with the config change and it does in fact look like depth buffer resolves are working correctly, and I don't see any unknown format messages in the log file. Haven't noticed any issues yet.

However, interestingly enough I have noticed a performance regression from version 2.4 with the NVR mod. Without it, performance is very slightly better. Of course, this is based on but a few repeated tests and on my personal setup. My guess is that with NVR, the GPU loads are pushed much higher than without it, and it's starting to be less of a CPU and more of a GPU bound scenario.

I am comparing DXVK 2.4 vs DXVK 2.7 on the same version of the mod.