https://bugs.winehq.org/show_bug.cgi?id=44315
Bug ID: 44315 Summary: Guild Wars 2 - Slow Performance since Wine 2.1 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: jonfarr87@gmail.com Distribution: Mint
Created attachment 60162 --> https://bugs.winehq.org/attachment.cgi?id=60162 Screenshot showing performance between old and newer Wine versions.
Wine 2.0 (with Staging patches) was the last version to run this game at a good performance, From 2.1 up to 3.0rc5 it results in a major framerate loss in every aspect of the game. The staging versions (up to 2.21) perform the same as "non staging" Wine.
While no other of my tested games were affected, it looks as if something in CSMT was changed and affected this particular title. I've tested this across multiple system configurations and the results are always the same.
Considering how much this game struggles to maintain a playable framerate, a loss of 15-25 frames (depending on the situation) is a bit excessive.
Screenshot attached, showing the frames difference in an instanced area of game where the performance can easily be used as a "benchmark".
Tests have been performed on 3 systems:
Ryzen 1700X 16GB DDR4 2800MHZ Ram Nvidia GTX 1060 / v384.98 Drivers
-------------------------------------------
i5-4590 8GB DDR3 Ram Nvidia GTX 960 / 384.98 Drivers
-------------------------------------------
i5-2400 8GB DDR3 Ram Nvidia GTX 760 / 375.66 Drivers
https://bugs.winehq.org/show_bug.cgi?id=44315
Chris Chris.Samberg@Gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Chris.Samberg@Gmail.com
--- Comment #1 from Chris Chris.Samberg@Gmail.com --- The problem is affecting me as well. Normally I get around 40-60 FPS on Windows but now I get less than 25 FPS in Wine.
CPU: AMD FX-8370 Memory: 32 GB 1600MHz DDR3 GPU: nVidia GTX 1080 Ti / v384.98 Drivers
Somewhat unrelated but may be worth noting: Guild Wars 2 has had problems with older AMD CPUs given that they don't have simultaneous multithreading (SMT). AMD's newer Ryzen CPUs and most of Intel's CPUs have SMT.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #2 from Chris Chris.Samberg@Gmail.com --- AMD's older CPUs will have less than 60 FPS.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #3 from Chris Chris.Samberg@Gmail.com --- I'm looking into the issue right now.
I'm sure Mr. Bugs will need more information on the issue, but I'll ask for some in the meantime. Run these both in the terminal while you play Guild Wars 2: - Wine Terminal output: "wine /path/to/Guild-Wars-2.exe > wine-output.txt" - nVidia GPU usage: "nvidia-smi -l 2 > gpu-usage.txt - CPU usage: Install sysprof and monitor wineserver and Gw2.exe. Take a picture with Shutter and upload that as an image.
https://bugs.winehq.org/show_bug.cgi?id=44315
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Component|-unknown |directx-d3d Status|UNCONFIRMED |NEW
--- Comment #4 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Ganni87 from comment #0)
Wine 2.0 (with Staging patches) was the last version to run this game at a good performance, From 2.1 up to 3.0rc5 it results in a major framerate loss in every aspect of the game. The staging versions (up to 2.21) perform the same as "non staging" Wine.
While no other of my tested games were affected, it looks as if something in CSMT was changed and affected this particular title. I've tested this across multiple system configurations and the results are always the same.
I think you're spot on. It looks like wine-staging 2.0 was the last version with the CSMT buffer map optimization hacks which, in some cases, could reduce CPU-GPU synchronization significantly and thus improve game performance.
We'll probably introduce something non-hacky to the same effect in wined3d at some point in the future.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #5 from Henri Verbeet hverbeet@gmail.com --- (In reply to Matteo Bruni from comment #4)
I think you're spot on. It looks like wine-staging 2.0 was the last version with the CSMT buffer map optimization hacks which, in some cases, could reduce CPU-GPU synchronization significantly and thus improve game performance.
We'll probably introduce something non-hacky to the same effect in wined3d at some point in the future.
It's a bit awkward to have this as a bug against the Wine product though, since it basically amounts to "D3D performance could be better". Wine never had those hacks—and for good reason—so GW2 performance in Wine shouldn't be any worse than it ever was. (If it is, please do a regression test.) At the same time, it doesn't seem al that likely that Staging would be willing to take this as their bug and work on bringing those hacks back in an acceptable form.
https://bugs.winehq.org/show_bug.cgi?id=44315
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |minor Summary|Guild Wars 2 - Slow |Buffer maps cause CPU-GPU |Performance since Wine 2.1 |synchronization (Guild Wars | |2)
--- Comment #6 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Henri Verbeet from comment #5)
(In reply to Matteo Bruni from comment #4)
I think you're spot on. It looks like wine-staging 2.0 was the last version with the CSMT buffer map optimization hacks which, in some cases, could reduce CPU-GPU synchronization significantly and thus improve game performance.
We'll probably introduce something non-hacky to the same effect in wined3d at some point in the future.
It's a bit awkward to have this as a bug against the Wine product though, since it basically amounts to "D3D performance could be better". Wine never had those hacks—and for good reason—so GW2 performance in Wine shouldn't be any worse than it ever was. (If it is, please do a regression test.) At the same time, it doesn't seem al that likely that Staging would be willing to take this as their bug and work on bringing those hacks back in an acceptable form.
Right, I guess I effectively rechristened this bug to mean "introduce a buffer map optimization". Let me update the bug to make that official.
Unless you think that's not useful either.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #7 from Ganni87 jonfarr87@gmail.com --- (In reply to Henri Verbeet from comment #5)
(In reply to Matteo Bruni from comment #4)
I think you're spot on. It looks like wine-staging 2.0 was the last version with the CSMT buffer map optimization hacks which, in some cases, could reduce CPU-GPU synchronization significantly and thus improve game performance.
We'll probably introduce something non-hacky to the same effect in wined3d at some point in the future.
It's a bit awkward to have this as a bug against the Wine product though, since it basically amounts to "D3D performance could be better". Wine never had those hacks—and for good reason—so GW2 performance in Wine shouldn't be any worse than it ever was. (If it is, please do a regression test.) At the same time, it doesn't seem al that likely that Staging would be willing to take this as their bug and work on bringing those hacks back in an acceptable form.
Unfortunately the performance loss is very much noticeable especially when you play the same game regularly for over 5 years.
As I've mentioned in my report, the rest of the games I play weren't affected. If there's a way to apply this hack manually to modern Wine versions I wouldn't mind building the binaries myself.
https://bugs.winehq.org/show_bug.cgi?id=44315
tt_1 herrtimson@yahoo.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |herrtimson@yahoo.de
https://bugs.winehq.org/show_bug.cgi?id=44315
Anders Dahlberg dahlberg@lysator.liu.se changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dahlberg@lysator.liu.se
https://bugs.winehq.org/show_bug.cgi?id=44315
mirh mirh@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch
--- Comment #8 from mirh mirh@protonmail.ch --- Can you check wine-pba? https://github.com/acomminos/wine-pba
https://bugs.winehq.org/show_bug.cgi?id=44315
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #9 from Ganni87 jonfarr87@gmail.com --- (In reply to mirh from comment #8)
Can you check wine-pba? https://github.com/acomminos/wine-pba
I'm compiling a 32bit Wine build with that as I write this, will have an answer soon :-)
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #10 from Ganni87 jonfarr87@gmail.com --- Tested the game using Wine Staging 2.21 + PBA / https://github.com/acomminos/wine-pba
The usual place I test the game at came back to an 80+ fps (as it was with 2.0 Staging), in other areas however it has improved by at least 5-10 fps and more importantly the fps drops are much less.
No graphical errors occurred. This was done using the 32bit version of the game. Once I figure out how to build a WoW64 version of Wine I will be able to test it a lot more.
Overall I'm satisfied with such results already.
https://bugs.winehq.org/show_bug.cgi?id=44315
Christian christian.frank@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |christian.frank@gmx.de
--- Comment #11 from Christian christian.frank@gmx.de --- (In reply to Ganni87 from comment #10)
Tested the game using Wine Staging 2.21 + PBA / https://github.com/acomminos/wine-pba
The usual place I test the game at came back to an 80+ fps (as it was with 2.0 Staging), in other areas however it has improved by at least 5-10 fps and more importantly the fps drops are much less.
No graphical errors occurred. This was done using the 32bit version of the game. Once I figure out how to build a WoW64 version of Wine I will be able to test it a lot more.
Overall I'm satisfied with such results already.
Very nice. Have you taken a look at the gpu load, did it increase noticable ?
https://bugs.winehq.org/show_bug.cgi?id=44315
duozerk ben@tokidev.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ben@tokidev.fr
--- Comment #12 from duozerk ben@tokidev.fr --- It seems this issue also occurs with The Witcher 3 and Kingdom Come: Deliverance (see bug #44682), that is: great perfs on 2.21-staging, much worse perfs in 3.3 and 3.3-staging, and the issue seems to be fixed (mostly) when applying wine-pba on top of 3.3-staging. Both apps are launched using wine64. I've taken the liberty of linking both games, and Guild Wars 2, to this ticket.
As per your question, for me at least, GPU usage (as seen through nvidia-settings) in Kingdom Come: Deliverance appears to be around 65% (it hovers between 60 and 70).
https://bugs.winehq.org/show_bug.cgi?id=44315
Shmerl shtetldik@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |shtetldik@gmail.com
--- Comment #13 from Shmerl shtetldik@gmail.com --- Can you please rename the bug to be more generic (it's not limited to GW2).
https://bugs.winehq.org/show_bug.cgi?id=44315
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Buffer maps cause CPU-GPU |Buffer maps cause CPU-GPU |synchronization (Guild Wars |synchronization (Guild Wars |2) |2, The Witcher 3) CC| |joseph.kucia@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #14 from duozerk ben@tokidev.fr --- For what it's worth, based on this reddit post:
https://www.reddit.com/r/wine_gaming/comments/82pt5j/some_tests_with_wine_33...
It seems many more games than the three listed are impacted.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #15 from mrdeathjr28@yahoo.es --- (In reply to duozerk from comment #14)
For what it's worth, based on this reddit post:
https://www.reddit.com/r/wine_gaming/comments/82pt5j/ some_tests_with_wine_33_vanilla_pba/
It seems many more games than the three listed are impacted.
If you want more can follow this theme here
https://github.com/acomminos/wine-pba/pull/26
https://bugs.winehq.org/show_bug.cgi?id=44315
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=44315
Daniel Oom oom.daniel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oom.daniel@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=44315
Kai Krakow kai@kaishome.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kai@kaishome.de
https://bugs.winehq.org/show_bug.cgi?id=44315
caleb@phobeus.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |caleb@phobeus.de
https://bugs.winehq.org/show_bug.cgi?id=44315
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #16 from Shmerl shtetldik@gmail.com --- I tested Wine pba with regular Wine - it doesn't really improve performance much for the Witcher 3 for example.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #17 from Kai Krakow kai@kaishome.de --- I tested it here, too: Performance is much worse compared to vanilla wine with NVIDIA buffer hacks. And also rendering is completely messed up with foliage completely missing (interestingly, it still casts shadows).
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #18 from Shmerl shtetldik@gmail.com --- (In reply to Kai Krakow from comment #17)
I tested it here, too: Performance is much worse compared to vanilla wine with NVIDIA buffer hacks. And also rendering is completely messed up with foliage completely missing (interestingly, it still casts shadows).
You can fix rendering with PBA by increasing heap sizes. See:
* https://github.com/acomminos/wine-pba/issues/46#issuecomment-375942122 * https://github.com/acomminos/wine-pba/issues/47
Performance is still bad though.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #19 from mirh mirh@protonmail.ch --- https://github.com/acomminos/wine-pba/issues/11#issuecomment-377791207 As I reported here, mesa (or gallium? Or just amd driver? Not sure) is highly bugged w/ ARB_buffer_storage.
That exact issue calling the total opposite result than OP being quite an evident proof.
https://bugs.winehq.org/show_bug.cgi?id=44315
Freso bugs.winehq.org@freso.dk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bugs.winehq.org@freso.dk
https://bugs.winehq.org/show_bug.cgi?id=44315
zzzzzyzz@hacari.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz@hacari.org
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #20 from Shmerl shtetldik@gmail.com --- Is there any progress with this?
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #21 from Kai Krakow kai@kaishome.de --- I lately tried Wine Staging with Witcher 3 and it was performing really bad with Witcher 3. Are there chances that people seeing really bad Witcher 3 performance using Staging? Especially the D3D11 deferred context patch series is problematic. Using vanilla or not using D3D11 deferred context patches makes the game run much better (almost smooth).
I also tried DXVK (which compiles as a separate set of DLLs, no patching needed, uses Vulkan) and besides lots of ugly graphical glitches, the game runs perfectly smooth (60+ FPS with some rare stutters what is probably caused by shader compilation). With DXVK, also Skyrim SE runs without problems and perfectly smooth.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #22 from Shmerl shtetldik@gmail.com --- Regular Wine performs quite badly for me with wined3d, GPU is underutilized so it doens't look like a staging related issue, but may be staging performs even worse.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #23 from Henri Verbeet hverbeet@gmail.com --- (In reply to Shmerl from comment #20)
Is there any progress with this?
We are actively looking into this, but unfortunately I can't give you an ETA.
https://bugs.winehq.org/show_bug.cgi?id=44315
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sr-tream@yandex.ru
--- Comment #24 from Matteo Bruni matteo.mystral@gmail.com --- *** Bug 44638 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #25 from Shmerl shtetldik@gmail.com --- Is this a related fix? https://github.com/zfigura/wine/blob/esync/README.esync
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #26 from Shmerl shtetldik@gmail.com --- I tested esync - it didn't improve framerate for TW3 for me:
https://i.imgur.com/4foGfC0.jpg
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #27 from Zebediah Figura z.figura12@gmail.com --- (In reply to Shmerl from comment #25)
Is this a related fix? https://github.com/zfigura/wine/blob/esync/README.esync
No, that is unrelated. This bug is about synchronization between the CPU and GPU, which should ideally be nonpresent. That patchset is aimed toward reducing the overhead of synchronization between multiple (CPU) threads.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #28 from Shmerl shtetldik@gmail.com --- (In reply to Zebediah Figura from comment #27)
That patchset is aimed toward reducing the overhead of synchronization between multiple (CPU) threads.
Got it, thanks! Is there some list of games known to benefit from it?
https://bugs.winehq.org/show_bug.cgi?id=44315
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #29 from Zebediah Figura z.figura12@gmail.com --- (In reply to Shmerl from comment #28)
(In reply to Zebediah Figura from comment #27)
That patchset is aimed toward reducing the overhead of synchronization between multiple (CPU) threads.
Got it, thanks! Is there some list of games known to benefit from it?
There's no compiled list, but generally only more recent games—such as have made heavy use of threading—will see a performance increase. If you have any questions about it, please feel free to ask, but ideally let's not pollute this bug with unrelated discussion.
https://bugs.winehq.org/show_bug.cgi?id=44315
Andrew Wesie awesie@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |awesie@gmail.com
--- Comment #30 from Andrew Wesie awesie@gmail.com --- I was unable to reproduce the performance regression between wine-staging-2.21 (CSMT enabled) and wine-staging-3.14, with:
Guild Wars 2 Intel i5-4690 AMD Radeon R9 290 (with Mesa 18.0.5)
Is this only an issue with NVIDIA cards / driver?
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #31 from Shmerl shtetldik@gmail.com --- No, it's a general issue. You can still observe it with the Witcher 3.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #32 from mirh mirh@protonmail.ch --- OP had mentioned 2.21-staging *plus pba* to be the 'golden' release in comment #10, to be fair. If you can't test it otherwise, 2.0-staging was the last good one.
Also for the records of any nvidia user: 390.87 and 396.54 fixed a long standing important performance regression (just to further mess bisecting, yay!)
https://bugs.winehq.org/show_bug.cgi?id=44315
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #33 from mirh mirh@protonmail.ch --- https://www.reddit.com/r/linux_gaming/comments/9fko3n/guild_wars_2_with_wine...
Friendly reminder pba can give you a 50% performance boost, in GW2 with nvidia cards.
And Kai (the only one reporting it was faulty on nvidia) never got back to test it with the right params.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #34 from Kai Krakow kai@kaishome.de --- (In reply to mirh from comment #33)
https://www.reddit.com/r/linux_gaming/comments/9fko3n/ guild_wars_2_with_winestaging_pba_esync_pure_love/e5z12tf/?context=2
Friendly reminder pba can give you a 50% performance boost, in GW2 with nvidia cards.
And Kai (the only one reporting it was faulty on nvidia) never got back to test it with the right params.
I could retry and integrate it into my Proton build and also my personal gaming wine build.
Is it only DX11 games benefiting from this or also others? And I guess if running DXVK, this patchset would be completely skipped, not running any code of it?
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #35 from mirh mirh@protonmail.ch --- Pba was originally created by comminos for World of Warcraft actually. (and if I really had to say it: I think it's almost basically the only obstacle for wined3d for sacred "dxvk level" performance)
My theory was that people were reporting "different results" because GL_ARB_buffer_storage is bugged to hell on radeon/mesa. But comment 17 of yours (contrarily to others, and my narrative, duh) claimed even for nvidia pba sucked.
After this last testimony it makes for *a lot* of improvement though, I am really really wondering whether you couldn't have done something wrong yourself instead. If you could re-check....
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #36 from Kai Krakow kai@kaishome.de --- Okay, I looked into it. There are a few issues I'm seeing with testing this separately (and thus I didn't yet):
1. Original wine-pba hasn't seen any update since some months, and there are a lot of forks out there of probably very different quality. Which one is the latest reliable source to use?
2. The wine-pba patchset doesn't include a dependency file on which individual staging patchsets it depends, and I'd rather not apply the whole staging to my build (it would probably create some conflicts I'd like to prevent).
Looking back in my memories, these were the main reasons why I gave up on following this although I still think this could be a great patchset with great potential. Kudos to acomminos for this work.
Besides that: Has pba been considered for inclusion into wine-staging?
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #37 from mirh mirh@protonmail.ch --- Idk, maybe we could CC Zebediah or Alistair?
Anyway, latest pba everybody seems to refer to is one of these https://gitlab.com/users/Firer4t/projects
For other references, maybe this could be of help? https://github.com/Tk-Glitch/PKGBUILDS/tree/master/wine-tkg-git
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #38 from Kai Krakow kai@kaishome.de --- (In reply to mirh from comment #37)
Idk, maybe we could CC Zebediah or Alistair?
I think Zebediah is already CC'ed on the bug...
Anyway, latest pba everybody seems to refer to is one of these https://gitlab.com/users/Firer4t/projects
Helps, thanks. Although I find Gitlab hard to follow and hard to navigate...
For other references, maybe this could be of help? https://github.com/Tk-Glitch/PKGBUILDS/tree/master/wine-tkg-git
This look definitely interesting.
I'll put some efforts into this but it'll take some time.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #39 from Zebediah Figura z.figura12@gmail.com --- Andrew Comminos' "wine-pba" patchset is hugely invasive, completely unmaintained, difficult to understand and in an area that neither Alistair nor I have more than passing knowledge of. Put simply, the maintenance burden is too much for us to accept it into Staging.
https://bugs.winehq.org/show_bug.cgi?id=44315
mirh mirh@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum@codeweavers.com
--- Comment #40 from mirh mirh@protonmail.ch --- Putting aside Firerat seems *very* available to get behind this, now that I think andrew had mentioned this to be getting directly upstreamed in proton tracker. Like a month ago.
Is there any update?
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #41 from Kai Krakow kai@kaishome.de --- It looks like pba requires inclusion of many (if not all) d3d staging patches - which includes the deferred context patches. Apparently, these also depend on the nvapi patches which is a no-go if you want to allow using dxvk: While it works, it slows dxvk down because it has to deal with command streams in games then (resulting from nvapi) and it cannot do so and complains loudly. There is no support for this in Vulkan so it's unlikely to be supported in dxvk any time soon.
But: If someone would work on removing the nvapi dependency from the deferred context patches, I would work on importing the pba patches into my wine-proton branch and into my wine-gaming branch. I think even without pba, the deferred context patches could be a benefit.
What I don't like about the pba patches is that it requires to manually adjust the heap space. Thanks to Fireat, at least this can be done with environment variables. The next step would be to make it more automatic. I would opt-in to work on such a patch if the above issues with nvapi and other dependencies are fixed. But I'm far far away from understanding how pba integrates with the rest of the wine d3d.
It is also difficult to follow the individual changes that are done with the various wine branches that integrate pba because most of the time these are an undefined collection of various staging and pba patches squashed together into one single, huge patch committed to the repository. This shouldn't be done if you want others to also work on your branches. It also prevents from reworking the individual commits to integrate better with wine staging and refactor them to be less intrusive. This really needs some love and work.
Currently, I rebased proton to wine-3.16 which was a lot of headache work due to the vulkan fullscreen hacks not applying cleanly. But the result is very rewarding: Shadow of Tomb Raider went from 19 fps or 31 fps in my system, and a lot of other bugs related to focus-out events (icon-sized game when focusing back in, game freezes) and gaming windows doing full-screen are fixed with that. BTW: Thanks a lot to all the guys working on the official proton wine branch and their individual own wine branches: You have done really great work, I want to mention Zeb, Andrew and Aric especially here for their work on threading improvements, input improvements (with improved force-feedback) and audio improvements.
The branch is here if someone is interested (but it's not to be used as a stand-alone wine prefix, it's for integration with proton because it includes the steam client hacks):
https://github.com/kakra/wine/releases/tag/wine-proton_3.7-3.16-unofficial-1
BTW: I don't think there's a chance to get pba upstreamed into wine any times soon without the inter-dependencies with wine-staging being resolved and making the changes to the code more easy to follow. But this only means we should work on it.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #42 from Zebediah Figura z.figura12@gmail.com --- (In reply to Kai Krakow from comment #41)
It looks like pba requires inclusion of many (if not all) d3d staging patches - which includes the deferred context patches. Apparently, these also depend on the nvapi patches which is a no-go if you want to allow using dxvk: While it works, it slows dxvk down because it has to deal with command streams in games then (resulting from nvapi) and it cannot do so and complains loudly. There is no support for this in Vulkan so it's unlikely to be supported in dxvk any time soon.
For what it's worth, the dependency here is artificial; it was a sledgehammer solution to the problem that the two patches kept interacting poorly during rebases (in specific, I believe git kept trying to apply the nvapi patches in the wrong place).
BTW: I don't think there's a chance to get pba upstreamed into wine any times soon without the inter-dependencies with wine-staging being resolved and making the changes to the code more easy to follow. But this only means we should work on it.
Indeed, I suspect Henri et al. would be very happy to help work together with people to optimize buffer mapping—whether that takes a similar form to Andrew's patchset or not.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #43 from Kai Krakow kai@kaishome.de --- (In reply to Zebediah Figura from comment #42)
(In reply to Kai Krakow from comment #41)
It looks like pba requires inclusion of many (if not all) d3d staging patches - which includes the deferred context patches. Apparently, these also depend on the nvapi patches which is a no-go if you want to allow using dxvk: While it works, it slows dxvk down because it has to deal with command streams in games then (resulting from nvapi) and it cannot do so and complains loudly. There is no support for this in Vulkan so it's unlikely to be supported in dxvk any time soon.
For what it's worth, the dependency here is artificial; it was a sledgehammer solution to the problem that the two patches kept interacting poorly during rebases (in specific, I believe git kept trying to apply the nvapi patches in the wrong place).
This is good news and makes me want to experiment with this.
And yes, I see this a lot with Git... Parts of function bodies may end up in the wrong function after merge due to very similar structure of nearby functions, especially with rerere enabled. A solution here is to refactor out the similarities into helper functions or move the invasive patch into its own file and just reference that with a function call.
I found that meld is a very nice tool to help with that. I used kdiff3 before which is very convenient because it does a lot of stuff automatically but it is often also very wrong with its decisions. The meld tool was which finally enabled me to rebase the fullscreen hacks properly and discover that actually one git revert was missing to add back in what was refactored out before.
BTW: I don't think there's a chance to get pba upstreamed into wine any times soon without the inter-dependencies with wine-staging being resolved and making the changes to the code more easy to follow. But this only means we should work on it.
Indeed, I suspect Henri et al. would be very happy to help work together with people to optimize buffer mapping—whether that takes a similar form to Andrew's patchset or not.
I'll look into it and try to understand what it does but I'm not sure if I'll be successful with it because I lack the time to deeply work into the wine code and DX in general. I think I only got a very small glimpse of that while I rebased proton 3.7 to wine 3.16. Maybe we can start with adjusting the code to no longer show these rebase conflicts - but this is probably where my help would end currently.
https://bugs.winehq.org/show_bug.cgi?id=44315
Firerat firer4t@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |firer4t@googlemail.com
--- Comment #44 from Firerat firer4t@googlemail.com --- (In reply to Kai Krakow from comment #41)
It looks like pba requires inclusion of many (if not all) d3d staging patches
This is not true, PBA requires no staging patches.
I believe the reason PBA was crafted against staging was that some staging was required in order for Retail WoW to run correctly. Although that is a guess, I could be wrong...
Historically patching wine-devel was trivial, only really had to deal with the missing wined3d-csmt/Makefile.in. Since wine-staging 3.5, when the wined3d-csmt was dropped, applying the PBA patchset to wine-devel is even easier.
for a while I ran wine-devel-pba without issue I belive Shmerl has firsthand experience with PBA on wine-devel, perhaps they can offer some insight.
currently I'm looking at making my envvar based patch less hacky, dropping some junk from it and moving the tunables into wined3d-main.c's wined3d_dll_init
PBA toggle ( default off ) geo / cb heap size ( default 512 / 128 ) these tunables will be in registry, or via envvar (envvar winning).
tbh, that is all done, at least mostly. don't get too excited by it, from a users perspective very little will change , they will just have to turn PBA on if they want it instead of off if they don't.
(In reply to Kai Krakow from comment #41)
It is also difficult to follow the individual changes that are done with the various wine branches that integrate pba because most of the time these are an undefined collection of various staging and pba patches squashed together into one single, huge patch committed to the repository
yeah, I guess they didn't use `patchinstall.sh --backend=git-am` slower but so much better
sadly that doesn't help much with wine-staging, instead of adding a patch to a patchset to alter functionality they edit existing patch!
check git history of programs/winecfg/winecfg.rc , apparently the current version of csmt toggle was commited Sun Dec 14 20:42:45 2014 +0100 The actual history is missing, like someone went at it with a sledgehammer. I don't know how often that kind of thing happeneds, but it means I cannot really trust the history of wine-staging patches .. and I don't fancy reading diffs of diffs to figure out who did what when.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #45 from Kai Krakow kai@kaishome.de --- Okay, I've updated my proton branch with PBA and it's impressive how far it has come: The Witcher 3 looks a bit different (nothing wrong but subtly different) than with DXVK but it plays exceptionally well with it (except some intermittent freezes after scene changes).
I've then added the deferred contexts patches but needed to resolve some conflicts - but in the end it worked. I've successfully run Path of Exile with this but there are very visible occasional freezes and very inconsistent FPS. But at least it works. Dynamic resolution kicks in very often, this almost never happens with DXVK.
I've also tried Shadow of Tomb Raider which looks very strange with WineD3D. It reminds me of the early days playing Witcher 3 with WineD3D with polygons sticking out of models, parts of models completely missing, and polygons flickering across the whole scene (but without the performance hit that could be seen in Witcher 3). The benchmark shows it's 48% CPU bound (vs. 12% with DXVK), with about half the avg FPS.
Loading times without DXVK are a lot longer - I mean really a lot (cold shader cache).
Here's my branch (to be used as Proton drop-in): https://github.com/kakra/wine/releases/new?tag=wine-proton_3.7-3.16-unoffici...
Thanks to Zeb and Firer4t for the tips on patches dependencies, and mirh for helpful links.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #46 from mirh mirh@protonmail.ch --- https://www.winehq.org/pipermail/wine-devel/2018-September/131484.html I'm pretty baffled by how, yet again, a relatively plain 15yo feature (related to ARB_buffer_storage too, nonetheless) is only getting now "discovered"
I wonder what else is left that could be neatly profiled
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #47 from Zebediah Figura z.figura12@gmail.com --- (In reply to mirh from comment #46)
https://www.winehq.org/pipermail/wine-devel/2018-September/131484.html I'm pretty baffled by how, yet again, a relatively plain 15yo feature (related to ARB_buffer_storage too, nonetheless) is only getting now "discovered"
I wonder what else is left that could be neatly profiled
Perhaps you should take up your profiler and find out.
Remember that everyone here is working in their spare time—or, if they are being paid to work, they are working on specific things. Complaining that they are not working on the parts of D3D that you want to be worked on, does more harm than good.
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #48 from Henri Verbeet hverbeet@gmail.com --- Essentially, what we have is a fairly small number of people doing constructive work by investigating issues, sending patches, and making sure those patches are suitable to commit. We also have a much larger group of people spending most of their time on complaining on the internet about the aforementioned group of people.
https://bugs.winehq.org/show_bug.cgi?id=44315
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=44315
--- Comment #49 from mirh mirh@protonmail.ch --- Well, the "GW2 guy" on Andrew's repo just reported to be super happy with results of pba now, with an amd card (I would almost dare to say performance is just slightly short of the expected Windows one)
AFAICT he's using mesa 18.3 with lutris's default esync-staging-pba-3.18 (based on TK patches which are based on firerat's work). And no knob or switch.
Maybe there aren't problems anymore? (/s)
https://bugs.winehq.org/show_bug.cgi?id=44315
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #50 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-6.5?
https://bugs.winehq.org/show_bug.cgi?id=44315
Daniel Oom oom.daniel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|oom.daniel@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=44315
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |2.1 Keywords| |Abandoned?
https://bugs.winehq.org/show_bug.cgi?id=44315
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|Abandoned? |performance
--- Comment #51 from Zeb Figura z.figura12@gmail.com --- I think it's long past time this bug was closed. The optimizations for streaming buffer mapping across the CS were implemented in Wine 8.0. If there are any applications that still perform worse than Windows, please file individual new bugs for them.
https://bugs.winehq.org/show_bug.cgi?id=44315
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #52 from Zeb Figura z.figura12@gmail.com --- (In reply to Zeb Figura from comment #51)
I think it's long past time this bug was closed. The optimizations for streaming buffer mapping across the CS were implemented in Wine 8.0. If there are any applications that still perform worse than Windows, please file individual new bugs for them.
Actually resolving.
https://bugs.winehq.org/show_bug.cgi?id=44315
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #53 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.13.
https://bugs.winehq.org/show_bug.cgi?id=44315
Jinoh Kang jinoh.kang.kr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jinoh.kang.kr@gmail.com
--- Comment #54 from Jinoh Kang jinoh.kang.kr@gmail.com --- *** Bug 51836 has been marked as a duplicate of this bug. ***