https://bugs.winehq.org/show_bug.cgi?id=57834
Bug ID: 57834 Summary: Regression: Cyberpunk 2077 doesn't load with CyberEngine Tweaks Product: Wine Version: 10.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: shtetldik@gmail.com Distribution: ---
Between Wine 10.0 and 10.1 some regression occurred that causes Cyberpunk 2077 with cyber engine tweaks plugin not to load (without CET it works fine in 10.1 too).
CET is loaded in general by overriding version.dll as native, builtin.
The only suspicious error in the log that I see is this:
0184:fixme:graphics:ShutdownBlockReasonCreate (0000000000030056, L"Generating error report"): stub
I'm running the game with usual things like
* esync from staging * dxvk / vkd3d-proton
https://bugs.winehq.org/show_bug.cgi?id=57834
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #1 from joaopa jeremielapuree@yahoo.fr --- dvxk - proton are not supported in this tracker. Please report to them
Or try with vanilla wine in a fresh new prefix and report here again.
https://bugs.winehq.org/show_bug.cgi?id=57834
--- Comment #2 from Shmerl shtetldik@gmail.com --- This is not an issue with dxvk and dxvk-proton but with some upstream Wine component.
It's impossible to run the game suing vanilla wine for all practical purposes, so your proposal is not really helping troubleshoot the issue.
I'll try to bisect the bug.
https://bugs.winehq.org/show_bug.cgi?id=57834
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=57834
--- Comment #3 from Shmerl shtetldik@gmail.com --- I found the first offending commit where things become broken:
https://gitlab.winehq.org/wine/wine/-/commit/33756286efb9e6b58831b01b9f2ef4d...
But I have no idea how that's related really.
https://bugs.winehq.org/show_bug.cgi?id=57834
--- Comment #4 from Hans Leidekker hans@meelstraat.net --- Can you retry with current git?
https://bugs.winehq.org/show_bug.cgi?id=57834
--- Comment #5 from Shmerl shtetldik@gmail.com --- (In reply to Hans Leidekker from comment #4)
Can you retry with current git?
It works, thank you! Which commit is fixing it?
https://bugs.winehq.org/show_bug.cgi?id=57834
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Shmerl from comment #5)
(In reply to Hans Leidekker from comment #4)
Can you retry with current git?
It works, thank you! Which commit is fixing it?
fe4ed10e, obviously.
https://bugs.winehq.org/show_bug.cgi?id=57834
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Regression SHA1| |33756286efb9e6b58831b01b9f2 | |ef4d7992a967a Fixed by SHA1| |fe4ed10ea18b064ed1431fbec5f | |36aa16d4a45f0 Summary|Regression: Cyberpunk 2077 |Cyberpunk 2077 doesn't load |doesn't load with |with CyberEngine Tweaks |CyberEngine Tweaks | Resolution|--- |FIXED
--- Comment #7 from Gijs Vermeulen gijsvrm@gmail.com --- Resolving FIXED, thanks for the report and bisection!
https://bugs.winehq.org/show_bug.cgi?id=57834
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 10.2.
https://bugs.winehq.org/show_bug.cgi?id=57834
FoX virtuousfox@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |virtuousfox@gmail.com
--- Comment #9 from FoX virtuousfox@gmail.com --- (In reply to Shmerl from comment #2)
This is not an issue with dxvk and dxvk-proton but with some upstream Wine component.
It's impossible to run the game suing vanilla wine for all practical purposes, so your proposal is not really helping troubleshoot the issue.
I'll try to bisect the bug.
Thanks for mentioning vkd3d-proton as just downloading prebuilt dlls from https://github.com/HansKristian-Work/vkd3d-proton/releases and putting them into game's folder made it finally work under wine. I wish someone would mention this in appdb.
https://bugs.winehq.org/show_bug.cgi?id=57834
--- Comment #10 from Shmerl shtetldik@gmail.com --- (In reply to FoX from comment #9)
Thanks for mentioning vkd3d-proton as just downloading prebuilt dlls from https://github.com/HansKristian-Work/vkd3d-proton/releases and putting them into game's folder made it finally work under wine. I wish someone would mention this in appdb.
That's really self explanatory if you are playing any games on Linux including using upstream Wine. Simply always enable dxvk + vkd3d-proton (I symlink them in the prefix so I can update them independently). They are giving best performance and compatibility so it's sort of redundant to mention it in app db, it's an implicit expectation at this point.
https://bugs.winehq.org/show_bug.cgi?id=57834
--- Comment #11 from FoX virtuousfox@gmail.com --- (In reply to Shmerl from comment #10)
(In reply to FoX from comment #9)
Thanks for mentioning vkd3d-proton as just downloading prebuilt dlls from https://github.com/HansKristian-Work/vkd3d-proton/releases and putting them into game's folder made it finally work under wine. I wish someone would mention this in appdb.
That's really self explanatory if you are playing any games on Linux including using upstream Wine. Simply always enable dxvk + vkd3d-proton (I symlink them in the prefix so I can update them independently).
There is nothing "self-explanatory" in using a fork of wine's core subsystem about existence of which I haven't even heard until now. And there is no ready-to-use distro package for it either, while I'm too lazy to make it (rpm spec-scripts for dll compilation are some obtuse bullshit, I'll tell you what) and keep it updated along with my custom dxvk package. So it's a boon that I did not have to build it too myself.
They are giving best performance and compatibility so it's sort of redundant to mention it in app db, it's an implicit expectation at this point.
No, this is an obscure hack and exactly what appdb is for. I haven't seen it even mentioned anywhere during web-wide search for hacks to make CP2077 playable, it was all about giving up on wine and using proton. Nobody even said which part of proton makes it work.
https://bugs.winehq.org/show_bug.cgi?id=57834
--- Comment #12 from Shmerl shtetldik@gmail.com --- (In reply to FoX from comment #11)
No, this is an obscure hack and exactly what appdb is for. I haven't seen it even mentioned anywhere during web-wide search for hacks to make CP2077 playable, it was all about giving up on wine and using proton. Nobody even said which part of proton makes it work.
It's not an obscure hack and has been around for years at this point? dxvk and vkd3d-proton rely on modern features of Vulkan without limitations, which allows them to provide implementations of D3D9 - D3D12 that have very good performance.
Upstream Wine has to accommodate limitations of translating Vulkan to Metal on macOS which limits features of Vulkan it relies on, that's why on Linux upstream Wine's implementation leaves some performance on the table so to say.
If you weren't aware of that - well now you are. But this has been so for a quite a while already and it's the primary reason to always use dxvk + vkd3d-proton for gaming on Linux even if you use upstream Wine.
https://bugs.winehq.org/show_bug.cgi?id=57834
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #13 from Zeb Figura z.figura12@gmail.com --- (In reply to Shmerl from comment #12)
It's not an obscure hack and has been around for years at this point? dxvk and vkd3d-proton rely on modern features of Vulkan without limitations, which allows them to provide implementations of D3D9 - D3D12 that have very good performance.
Upstream Wine has to accommodate limitations of translating Vulkan to Metal on macOS which limits features of Vulkan it relies on, that's why on Linux upstream Wine's implementation leaves some performance on the table so to say.
Yeah, no, that's not why Wine "leaves some performance on the table".
https://bugs.winehq.org/show_bug.cgi?id=57834
--- Comment #14 from Shmerl shtetldik@gmail.com --- (In reply to Zeb Figura from comment #13)
Yeah, no, that's not why Wine "leaves some performance on the table".
Oh, but may be you can elaborate why. From what I've heard Wine needed to work with MoltenVK which by design can't support many recent Vulkan features. May be things have improved since then.
https://bugs.winehq.org/show_bug.cgi?id=57834
--- Comment #15 from Zeb Figura z.figura12@gmail.com --- The reason for the performance gap between DXVK and Wine's builtin D3D implementation (and, similarly, between vkd3d-proton and vkd3d)—such as it existed and sometimes still exists—has nothing to do with the underlying API, and everything to do with the amount of developer time that has been spent on each implementation.
There is no magic modern Vulkan feature that improves performance as significantly as people somehow think, and even if there were, the desire to support a broad range of Vulkan drivers, including MoltenVK, does not actually prevent us from using any such features.
The idea that "DXVK is focused on performance, whereas Wine is focused on compatibility" (or sometimes "correctness") is widespread, and completely wrong. Anyone who's spent time actually looking at the Wine codebase can find plenty of evidence that Wine is focused on performance. Fun fact also, we've got a whole database of targeted workarounds for driver bugs, or special code to avoid driver paths that are known to be slow; some people think we leave performance on the table because we refuse to do that and that's not correct either.
The only sense in which that's true is that, after 20 years of experience, we care quite a lot about designing the code to be maintainable and readable. We also care quite a lot about avoiding regressions. This leads to a style of development whereby large changes are planned out, and we attempt to account for all of the corner cases, before implementing things, it means writing tests, and it means we split changes into patches that a reviewer can easily understand. DXVK follows pretty much the opposite style of development as this. The effect is that DXVK can get one application working a lot faster, and then has to spend a lot of time fixing bugs and regressions, whereas we have to spend comparatively little time fixing bugs but it takes a lot more time before a feature is fundamentally ready.
In 2018, back when DXVK was starting to work well for a few applications, half of Wine's Direct3D team—then about four people—was contracted to work on vkd3d, bringing it up from scratch to a fundamental implementation. The other half was still working on d3d9, as well as things like GL core profile support. Despite this they still managed to spend some time on d3d11, but they had quite a lot of things to implement:
(1) An entire Vulkan renderer—as it became clear would be necessary, not because Vulkan "allows better performance" (it doesn't, not really, except for some very stupid missing pieces in GL that don't have anything to do with the latter's design flaws) but because it was becoming clear that Khronos and driver developers would abandon GL.
The amount of time that Vulkan, with its stupid API break and even stupider API design, has cost us, and is continuing to cost us, cannot be stated enough, and I find it infuriating because nobody who talks about Vulkan ever acknowledges this.
(2) Direct3D 11 deferred contexts, which prevented a lot of games from working. Michael Müller wrote an implementation for this, but it was bolted on like spaghetti and didn't really allow for optimal performance. "Why didn't you just commit those patches?"
(3) Map acceleration across the command stream, which killed performance for anything d3d10/d3d11 and many things d3d9. This was what Andrew Comminos' "PBA" patch set was supposed to fix, but it was bolted on like spaghetti and arranged in an unreviewable way. "Why didn't you just commit those patches?"
By the way, one of the "stupid missing pieces" in GL is *still* killing performance in a way related to this. We'd like to switch to the Vulkan renderer by default, which is actually on par with DXVK in most games I try, but we can't do that until it's as featureful as the GL backend (doesn't cause regressions), which takes a lot of work!
Meanwhile, DXVK—in addition to following a different development model—was being written by a very talented individual who, importantly, had the free time to do nothing *but* work on d3d11, *and* moreover Philip was working on a new code base, without the need to worry about things like d3d9 or GL. This meant that he was able to get a few high-profile applications working very well a lot more quickly than Wine could, which naturally attracted a lot of attention.
Over the years that followed, the amount of time that CodeWeavers has spent on Linux Direct3D has only shrunk. We lost Józef, one of the most talented and productive members of the team, and while we've gained several other people since then (including myself), CW has spent all of the D3D team's time on MoltenVK (which is where pretty much all of the deficiencies are in the 3D stack on Mac), the HLSL compiler, and various client bugs not related to 3D. At this moment nobody is working on d3d12, and the only person working on ddraw-d3d11 is what little time I can spare that's not one of those other things, and all of tha time is *still* focused entirely on the fall out of the stupid @%$!! mess that is Vulkan. Have I mentioned how much I hate Vulkan?
Meanwhile, all of the big 3 problems I listed have been fixed, several years ago in fact, and Wine's d3d11 implementation is actually quite good. But nobody has noticed, both because everyone's attention is on DXVK, and because optimal performance still relies on Vulkan, which can't be the default yet. And when there are bugs—and several users I am infinitely thankful towards are still reporting them—I simply don't have the time to do anything about them.
https://bugs.winehq.org/show_bug.cgi?id=57834
--- Comment #16 from Shmerl shtetldik@gmail.com --- (In reply to Zeb Figura from comment #15)
Meanwhile, all of the big 3 problems I listed have been fixed, several years ago in fact, and Wine's d3d11 implementation is actually quite good. But nobody has noticed, both because everyone's attention is on DXVK, and because optimal performance still relies on Vulkan, which can't be the default yet. And when there are bugs—and several users I am infinitely thankful towards are still reporting them—I simply don't have the time to do anything about them.
Thanks for clarifying that it's more of a resources / focus problem and not really some conceptual blocker like compatibility needs. The latter is somehow indeed a common a perception and it's good that you explained that it's wrong and Wine can have good performance without being blocked by MoltenVK and similar cut down Vulkan backends.
Most of the new the games these days are D3D12 anyway, so that really is the biggest elephant in the room, but D3D11 is of course still quite important too.
If at some point upstream Wine will catch up to dxvk / vkd3d-proton from resources standpoint, I'd be interested in trying using that to compare / report issues.
-
WineHQ Bugzilla