https://bugs.winehq.org/show_bug.cgi?id=57233
Bug ID: 57233 Summary: BeamNG.drive blocks on startup with black screen/window. Product: Wine Version: 9.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs@winehq.org Reporter: logos128@gmail.com Regression SHA1: 278ca7f68d727639b3389b78c363134fa2bd32a8 Distribution: ArchLinux
The problem occurs in both d3d11 and Vulkan rendering modes, that the game provides.
After bisecting it, found that "winex11: Only update the client window position in sync_client_position." (278ca7f) causes the regression. I have confirmed this by reverting just the aforementioned commit on the top of the 9.18 tree, and the game started normally and ran without issues.
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #1 from Ivo Ivanov logos128@gmail.com --- Created attachment 77150 --> https://bugs.winehq.org/attachment.cgi?id=77150 beamng_issue.gz
WINEDEBUG=-all,+timestamp,+pid,+tid,+loaddll,+x11drv,+win
The call to X11DRV_WindowPosChanged() that should call sync_client_position()/XConfigureWindow() is on row 3046.
I use DXVK for d3d11, since the game doesn't work with wine's version.
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #2 from Ivo Ivanov logos128@gmail.com --- Created attachment 77151 --> https://bugs.winehq.org/attachment.cgi?id=77151 beamng_revert_fix.gz
WINEDEBUG=-all,+timestamp,+pid,+tid,+loaddll,+x11drv,+win
This is with the regression commit reverted on the top of the 9.18 tree. The game starts properly and works without issues.
The call to X11DRV_WindowPosChanged() is on row 3114. The call to sync_client_position()/XConfigureWindow() is on row 3115.
https://bugs.winehq.org/show_bug.cgi?id=57233
Ivo Ivanov logos128@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=57233
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net Summary|BeamNG.drive blocks on |Multiple games using DXVK |startup with black |show black screen/window on |screen/window. |startup (BeamNG.drive, | |Wargaming.net games) Keywords| |regression Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #3 from Anastasius Focht focht@gmx.net --- Hello folks,
I can confirm this. Various games are affected when using DXVK. Just a black screen and endless spam of DXVK info messages in console.
https://github.com/doitsujin/dxvk/releases
DXVK 2.3.1 (oldest tested) through 2.4.1 (latest)
Reverting the offending commit on current master HEAD makes things work again. Why DXVK? Significantly better graphics performance with older machines/GPUs.
Regards
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #4 from Ivo Ivanov logos128@gmail.com --- The problem is present even when using the Vulkan rendering mode in BeamNG.drive. Although the game still seems to load both dxgi.dll and d3d11.dll (DXVK shows some debug messages). I tried Wine's dxgi/d3d11 dlls, but the game crashed with them.
Anyway, I don't think it's strictly DXVK related. From the provided logs is visible that X11DRV_WindowPosChanged() -> sync_client_position() doesn't call XConfigureWindow() on width/height changes, since this was removed from the function with the aforementioned commit. Probably as an optimization needed for the child window stuff.
I will try the game with the builtin dxgi/d3d11 in Vulkan rendering mode, to see if the issue is still present. (Hopefully it won't crash this way, as in d3d11 mode).
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #5 from Rémi Bernon rbernon@codeweavers.com --- Would you mind making logs with vulkan too?
WINEDEBUG=-all,+timestamp,+pid,+tid,+loaddll,+x11drv,+win,+vulkan
Fwiw I'm not reproducing the problem locally, but I think it could be an invalid assumption I made that mismatched client rect would cause the render thread to re-create its surface and sync its size: we only return VK_SUBOPTIMAL which may not trigger such recreation.
I'm considering whether to revert the change entirely, it's not a big deal but it was there to decouple a bit more the logic between the windowing thread and the rendering thread (which would be in charge of resizing the client rect).
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #6 from Ivo Ivanov logos128@gmail.com --- Created attachment 77188 --> https://bugs.winehq.org/attachment.cgi?id=77188 beamng_vulkan.gz
WINEDEBUG=-all,+timestamp,+pid,+tid,+loaddll,+x11drv,+win,+vulkan
This is the in-game Vulkan renderer (using the builtin dxgi/d3d11 - Wine 9.18). So it seems not related to DXVK. The game hangs with a black screen and needs to be forcefully terminated.
The call to X11DRV_WindowPosChanged() is on line 14792.
https://bugs.winehq.org/show_bug.cgi?id=57233
Ivo Ivanov logos128@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Multiple games using DXVK |Multiple games show black |show black screen/window on |screen/window on startup |startup (BeamNG.drive, |(BeamNG.drive, |Wargaming.net games) |Wargaming.net games)
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #7 from Ivo Ivanov logos128@gmail.com --- Created attachment 77189 --> https://bugs.winehq.org/attachment.cgi?id=77189 beamng_vulkan_revert_fix.gz
WINEDEBUG=-all,+timestamp,+pid,+tid,+loaddll,+x11drv,+win,+vulkan
The in-game Vulkan renderer with the regression commit reverted on the top of the 9.18 tree. The game works properly.
The call to X11DRV_WindowPosChanged() is on line 14702 followed by sync_client_position() on the next line.
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #8 from Rémi Bernon rbernon@codeweavers.com --- Created attachment 77193 --> https://bugs.winehq.org/attachment.cgi?id=77193 Possible fix
Thank you! Hmm, it's not completely clear what is going on though, but could the attached patch help still?
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #9 from Ivo Ivanov logos128@gmail.com --- Created attachment 77196 --> https://bugs.winehq.org/attachment.cgi?id=77196 beamng_vulkan_patch.gz
Thanks. Unfortunately the issue is still present.
I didn't mention before, but in vulkan rendering mode without the issue, the game starts windowed with default settings. When this issue is present the game starts with a black full-screen and hangs there. Also, when everything works properly, the game seems to launch a second cef render process (as it looks from the params). With the problem, though, it hangs in the first process, and doesn't launch the second cef process.
I have added 'event' to the winedebug env. This is with the provided patch applied on Wine 9.18.r221.g7c1fbc40b7e. The game is launched with default settings.
WINEDEBUG=-all,+timestamp,+pid,+tid,+loaddll,+x11drv,+win,+event,+vulkan
The call to X11DRV_WindowPosChanged() is on row 9459.
I'm using Manjaro (Arch) with kernel 6.10.11, XFCE in X11, Nvidia GTX 1080ti with driver 550.40.75 (the latest vulkan dev driver), several VC++ redists installed in the prefix and forced to native, .NET 4.8, dxvk build from latest HEAD.
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #10 from Ivo Ivanov logos128@gmail.com --- Created attachment 77197 --> https://bugs.winehq.org/attachment.cgi?id=77197 beamng_d3d11_patch.gz
WINEDEBUG=-all,+timestamp,+pid,+tid,+loaddll,+x11drv,+win,+event,+vulkan
This is in d3d11 mode. In this mode when the problem occurs, the game starts windowed (black window), as opposed to vulkan's full black screen. It also launches the second 'beamng.drive.x64.exe' cef process. The latest DXVK build from HEAD is used.
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #11 from Rémi Bernon rbernon@codeweavers.com --- Created attachment 77198 --> https://bugs.winehq.org/attachment.cgi?id=77198 Additional traces
Hmm... would you mind making another log with the attached patch for additional traces? Thanks a lot for the help!
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #12 from Rémi Bernon rbernon@codeweavers.com ---
This is in d3d11 mode. In this mode when the problem occurs, the game starts windowed (black window), as opposed to vulkan's full black screen.
Ah yeah the d3d11 mode seems to match my expectation, where it constantly recreates the swapchain. I still don't completely understand why it doesn't eventually succeed. I guess I'll just send a revert of the change for now.
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #13 from Ivo Ivanov logos128@gmail.com --- Created attachment 77199 --> https://bugs.winehq.org/attachment.cgi?id=77199 beamng_trace.tar.gz
Here are logs with the additional traces. Interesting the vulkan version calls wine_vkAcquireNextImageKHR() only once and then seems to wait indefinitely on thunk64_vkWaitForFences(). While the d3d11 version calls it many times without ever succeeding.
WINEDEBUG=-all,+timestamp,+pid,+tid,+loaddll,+x11drv,+win,+event,+vulkan
https://bugs.winehq.org/show_bug.cgi?id=57233
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #77193|0 |1 is obsolete| |
--- Comment #14 from Rémi Bernon rbernon@codeweavers.com --- Created attachment 77218 --> https://bugs.winehq.org/attachment.cgi?id=77218 Possible fix
I now better understand what is going on: the game creates a surface before the window resize and swapchain after the window resize, so the swapchain extents match the client area, but the surface does not.
The NVIDIA driver returns VK_ERROR_OUT_OF_DATE from vkAcquireNextImage, while AMD returns VK_SUBOPTIMAL. When VK_SUBOPTIMAL is returned the call succeeds, and images can be acquired and presented although they may end up distorted. This is why I'm not reproducing the problem on AMD.
With the vulkan renderer, the game doesn't even expect an error to occur here, and incorrectly waits on the fence forever. With the D3D11 renderer, the error triggers the swapchain recreation, but as we do not re-create or update the host surface size, it continues to return an error on the next call.
I'm attaching an alternate version of the fix to avoid going through the revert, if you don't mind testing. It fixes the VK_SUBOPTIMAL result for me, so I expect that it'll fix the VK_ERROR_OUT_OF_DATE on NVIDIA as well.
I think it's more future proof than the revert, if we consider that we might eventually need to allow multiple client surfaces for a window (to support cases where multiple APIs are used to render to the same HWND).
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #15 from Ivo Ivanov logos128@gmail.com --- Thank you very much! The game starts without issues now. Tested both d3d11 and vulkan renderers in windowed and full-screen mode.
https://bugs.winehq.org/show_bug.cgi?id=57233
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |1fe64cd59573473160186aa172c | |4bf5055510cd7 Status|NEW |RESOLVED
--- Comment #16 from Rémi Bernon rbernon@codeweavers.com --- Should be fixed with 1fe64cd59573473160186aa172c4bf5055510cd7.
https://bugs.winehq.org/show_bug.cgi?id=57233
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #17 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.20.
https://bugs.winehq.org/show_bug.cgi?id=57233
areebdurrani@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |areebdurrani@gmail.com
--- Comment #18 from areebdurrani@gmail.com --- I am still getting this exact bug in Crysis Remastered and Crysis 2 Remastered. If it helps, I heard somewhere these games call both DX11 and Vulkan during the same game session for some shader effects.
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #19 from areebdurrani@gmail.com --- I can also confirm that these games do work in WINE 9.17, and they stop working from WINE 9.18 forwards
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #20 from areebdurrani@gmail.com --- They both seem to work perfectly on wayland, just not on x11. This makes me think this is actually a seperate bug, one related to x1l and not to vulkan. I was too hasty commenting here. I am new to open source development and these kinds of mailing lists. I apologize for any inconvenience I may have caused.
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #21 from Rémi Bernon rbernon@codeweavers.com --- No worries, please open another bug if you still experience a (possibly different) broken application, especially if you can confirm that things worked with some older Wine versions.
Ideally, if you can build Wine yourself, we appreciate running git bisect to find out exactly which commit broke the application but it might be complicated with all the recent changes in the area.
https://bugs.winehq.org/show_bug.cgi?id=57233
--- Comment #22 from areebdurrani@gmail.com --- Thank you.
As an update, I have found that even vkcube is having issues on x11 after the newer NVIDIA drivers came out. This leads me to think that what I am experiencing is likely not a WINE bug, but rather a bug in either x11 or the NVIDIA drivers.
I will try to investigate a little more in the future before commenting here.