That sounds very odd. Can you send a screenshot from good and bad commit with DXVK_HUD=full ?

@Blisto91 Sure, screenshot from good 242ac20752245d2dac02e9c335fd7c1f36466a58 commit:

And screenshot from bad 83a294285e90c65554bc851c4d4a126aa15916a4 commit:

What is your setup like. Do you have multiple GPU's or monitors?
Does anything interesting get printed by Wine. I assume not, but just as a extra.

I only have one GPU and one monitor. What I can report of interesting is that my 3080 is listed twice in the in-game GPU selection menu (it's always been like this):

And if I enable DXVK_NVAPI, it correctly detects there's only one GPU, but for some reason reports it as low power:

This behavior is shared by both good and bad commits. Enabling/Disabling DXVK_NVAPI does not affect performance at all. I'll look at the wine logs if I find something interesting there too.

~I don't know if it would be helpful here, but might be good if you good make an apitrace for the devs https://github.com/doitsujin/dxvk/wiki/Using-Apitrace~

Edit: Actually before the above as i don't know how annoying that would be with this game. If you could post the Wine log when run with WINEDEBUG=+pid,+loaddll,+system,+debugstr,+seh
Also if you could attach the output of vulkaninfo

Sorry for the delay, here are the requested logs:
logs.tar.gz

Thank you for the logs.
Could i get you to try and run the game through regular Proton Experimental in Steam as a non steam game? Hopefully you should just be able to add the battlenet or wow exe itself directly from your current prefix install and set it's comparability to Proton Experimental without needing to touch anything else.
If the issue still shows then could you post a Proton log with just PROTON_LOG=+system,+xrandr,+x11drv %command%. Without gamemode or anything extra.

As I was using the flatpak version of both Steam and Bottles so it required a bit more steps to share the install directory between them (details below), but I can confirm it also happens on a regular Proton Experimental using a fresh prefix, here are the logs:
steam-15655447108700340224.log.tar.gz

It sure shouldn't happen, but it unfortunately does happen. Would a workaround for this kind of situation be conceivable? Looking at the commit, it seems the change were made for systems possessing an iGPU, could the old behavior be restored for systems who don't?

It doesn't, but if the underlying issue is on the Blizzard side of things there's not much else that can be done I assume. Either way it would solve the performance impact, which seems like an acceptable trade-off.

It also helped multi driver systems like amdvlk + radv. RE Engine games could freak out quite alot prior to it on multi GPU and driver systems.

I don't have any technical insight here mind you. Wonder if flatpak can affect it somehow.

@koplo199 Sorry for the chasing back and forth here. Could you also provide logs from the commit prior to the offending one like in your opening post, but with WINEDEBUG=+pid,+loaddll,+timestamp,+seh,+xrandr,+system

@Blisto91 Sure, here are the new logs:
logs.tar.gz

This last behavior seems to be linked to Battle.net itself, not by WoW. Launching WoW directly does not cause issues with the flip model, but launching only Battle.net without running any game does. Unfortunately, it also seems unrelated to the performance regression as I am also able to reproduce it with this method (launching WoW without Battle.net, and seeing the FLIP indicator).

Final edit: The FLIP issue was indeed unrelated to the performance regression, and was caused by gnome-shell: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6955

@koplo199 So i can myself reproduce a big perf drop when i change my vendor id to not match my GPU vendor (AMD).
But i'm confused as to why you still have a drop even when using nvapi as that should show your vendor id correctly as Nvidia. Could you also send a log where you have that enabled?

It would be most interesting to see how that goes with Proton without anything custom (possibly PROTON_ENABLE_NVAPI=1). That is, e. g. , without flatpak which is not a supported Proton configuration. Thing is, as this (afaik) is not the issue for everyone, so probably something should be triggering that in specific configuration.

@gofman I tried using with a fresh, regular (non-flatpak) steam and I confirm it also happens in this configuration. Here are the logs using PROTON_LOG=+pid,+loaddll,+timestamp,+seh,+xrandr,+system %command%, with and without PROTON_ENABLE_NVAPI=1:
steam-logs.tar.gz

This time, I did not symlinked the Program Files folder, I reinstalled everything from scratch. Please tell me if you need complementary logs/informations, I'll keep this setup installed in the meantime.

I might have an interesting new information: it seems WoW never attempts to load nvapi librairies on Linux. It is hinted in-game by the message NVAPI is disabled on Wine under the Low Latency Mode dropdown setting, and confirmed by the different logs where no loaddll entries are found for neither nvapi.dll or nvapi64.dll (and no DXVK-NVAPI messages are printed, even with DXVK_NVAPI_LOG_LEVEL=info).

Maybe WoW relies on nvapi to correctly detects NVIDA GPUs, and by disabling it on Linux so early in the process it breaks its own detection mechanism? It would explains why an RTX 3080 is incorrectly shown as (Low Power), and @Blisto91 maybe this is also why there still is a big drop in performance when reporting a matching vendor id for NVIDIA GPUs but not for AMD ones?

Thanks for the interesting find. So it looks like that the game is somewhat broken on Wine specific path, on which path it requeries dxgi output config each frame with Nvidia. This is not too much performant before the blamed commit as well, nor on Windows, although output enumeration became much slower with the blamed commit. I think mostly because in the current Proton (and in Wine before commit c2c9112bf8896d49a6af1ca1f73e563c5a7f909c) QueryDisplayConfig is much slower than EnumDisplayMonitors which was used before. Unfortunately the referenced commit caused massive regressions (not the direct commit fault, it triggered a lot of pre-existing issues). Those issues are believed to be fixed in Wine upstream now but that's a lot of sensitive changes which we cannot pull to Proton at once (also given that properly behaving games which avoid costly display config re-evaluation each frame don't suffer from this).

So I hope that it will be greatly improved once we get c2c9112bf8896d49a6af1ca1f73e563c5a7f909c and followups in Proton. Before that, if it is possible to check with upstream Wine + dxvk, it would be interesting if the issue is not there (or there to much less extent). Also maybe a temporary workaround using WINE_HIDE_NVIDIA_GPU=1 (instead of PROTON_ENABLE_NVAPI) will help.

It would explains why an RTX 3080 is incorrectly shown as (Low Power), and @Blisto91 maybe this is also why there still is a big drop in performance when reporting a matching vendor id for NVIDIA GPUs but not for AMD ones?

On that specific note. Interestingly i get the same "Low Power" marker on my main GPU when i spoof another vendor id than the one i have.

@koplo199 Could you when you have time test this Proton build in Steam with and without nvapi enabled to see if it makes a difference? Just need to check something. https://drive.proton.me/urls/ANJ8ACCZA8#4g9qbdLUTpq1
If you extract it into ~/.steam/steam/compatibilitytools.d/ it will show up as a compatibility option. Steam will need a restart if already running.

Edit: For flatpak i gather the path might be ~/.var/app/com.valvesoftware.Steam/data/Steam/compatibilitytools.d/ but i have not checked this myself as i don't have the flatpak version.

I can confirm that I'm affected by this regression as well, for me it went from ~300fps in dxvk 2.2 to ~60fps with dxvk 2.3
The game is only actually playable when switching the graphics API from dx11 to dx12 and using vkd3d instead. First time that vkd3d is faster than dxvk for me.

I retract my statement pending further notice. wine version seems to have a big impact, too
Downgrading wine from 8 to 7 makes this even worse, but also in dxvk 2.2, not just 2.3

OK downgrading to 2.2 made it even worse, in that case I only had 12fps where I before had over 700
Downgrading to 2.1 and the game runs smoothly again.

Tested with both wine 8 and 7, same results basically (wine 7 was slightly worse than wine 8)
Deleted the GLCache between all tests

Quality settings / render scale make no difference, my GPU is pinned at 30% utilization with or without vsync and in performance state P3 (P0 would be 3D performance state)

Are you sure this is the same issue? I'm a bit confused if you are saying this started in 2.2 or 2.3. The commit written about here was introduced in 2.2.
Please post a log

I would, but dxvk doesn't write logs despite having log level set to debug and log path set to a universally writable directory
(I know dxvk is loaded because the fps+version overlay is active, which confirms each of the versions for me, but it just refuses to write logs to file and I wouldn't know how to force it)

Either way it doesn't get my GPU into P0 performance/3D mode, and neither my CPU nor my GPU show more than 30% of utilization (no core higher than 30% on the CPU) (GPU is RTX 3080 like OP and CPU is a 5950X)

Is there some d3d call that turns the current window into a 3D context or something like that? No idea.

(non-demanding scene)

Same scene but with 2.1

Edit: the bottom screenshot tops out at 240 fps, because it's set to vsync, that's normal. with uncapped fps the behaviour in dxvk 2.2/2.3 is identical, while I get to 400-600 fps in this scene in dxvk 2.1

Since the issue links to a commit related to monitor enumeration as possible issue, I'll just add my monitor setup, which is
Primary monitor: 1440p@240Hz Horizontal
Secondary monitor: 1440p@85Hz Vertical

probably doesn't mean much, but eh.

FPS I get with 2.2(Lutris) and 2.3(Latest Git Commit) is ~63FPS with Wine-ge 8.
If I use wine-ge 7 I get 13fps with dxvk 2.2(Lutris) and ~32FPS with dxvk 2.3(latest git)
I do not have an iGPU and my 3080 has been detected by WoW as "Low Power" even with Wine 2.1 where performance is perfectly fine.

@koplo199 With the build found here https://github.com/doitsujin/dxvk/actions/runs/6467734807 would you be able to verify that launching with DXVK_CONFIG=dxgi.useMonitorFallback=True helps the issue?

@Blisto91 I confirm that using that build (alongside dxgi.useMonitorFallback=True) entirely fixes the issue!

(And sorry I missed your previous comment about a test with a particular Proton build, I was able to test it now on a regular Steam installation and for what it's worth it didn't seem to change anything)

Does it mean the workaround can now be added to config.cpp

We are a bit weary of adding it built in for every game as it has the potential of breaking some games in multi monitor or multi GPU setups.

Understandable, I just want to add that from my last testings the performance drop was really significative: ~50 FPS without the workaround and ~100 FPS with it activated. It was still very much playable, but that's with a 3080 at ~1440p; for some users it might cross the boundary between playable and unplayable, so I really don't know what would be the best option here.

As the regression seems to mainly affect NVIDIA cards, could it be activated for World of Wacraft by default if an NVIDIA card is detected (or with an Intel/AMD card if their hideXXXGpu option is enabled, as it apparently affect them too in that case)?
Or maybe more simply, couldn't it be made te be activated for all games when only one monitor/GPU is detected?

We are a bit weary of adding it built in for every game as it has the potential of breaking some games in multi monitor or multi GPU setups.

No need to add it for every game, just for World of Warcraft

As the regression seems to mainly affect NVIDIA cards, could it be activated for World of Wacraft by default if an NVIDIA card is detected (or with an Intel/AMD card if their is enabled, as it apparently affect them too in that case)?
Or maybe more simply, couldn't it be made te be activated for all games when only one monitor/GPU is detected?

I have AMD card and don't use hideXXXGpu option, but affected by this regression too

@koplo199 Try use my settings https://gist.github.com/Milor123/351517ec9741786b910f874826943975

As said above the config dxgi.useMonitorFallback is specifically meant to temporarily work around this issue for people with it. So no need for all that
It should be solved properly in Proton 9 once it is out.

@koplo199 @insunaa @kerriganx Are you able to verify that this is no longer an issue without the config when using the new Proton 9.0 beta or Experimental?

@koplo199 @insunaa @kerriganx Friendly double ping. I checked it out with my new Nvidia GPU and it seemed fine with Proton 9

Sorry for the delay, I was/am unable to test but there's no reason to believe it isn't fixed by Proton 9.

Many thanks to everyone involved in the resolution of the issue!

I updated to the git-latest today and the issue seems to be back

2.4 release version has the same issue, but I also didn't see any notable changes between 2.4 release and git latest

@Blisto91 (sorry for ping)

The dxvk workaround for this specific issue was pulled out because the proper fix was included in Proton 9 (and upstream Wine 9). It has been fixed there for a while now.

Lutris does not have Wine 9 or Proton 9 and probably never will, either. Is the suggested fix to downgrade to a previous version of dxvk?

If you are unable to use a newer Wine then yes I'd stick to 2.3.1 for now.

If you are unable to use a newer Wine then yes I'd stick to 2.3.1 for now.

Alright, thank you.