[Bug 47767] New: Airport Mania First Flight - Very slow loading times and awful performance
https://bugs.winehq.org/show_bug.cgi?id=47767 Bug ID: 47767 Summary: Airport Mania First Flight - Very slow loading times and awful performance Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: iodreamify(a)gmail.com Distribution: --- Created attachment 65248 --> https://bugs.winehq.org/attachment.cgi?id=65248 winedebug log The game starts and shows an intro screen but then only gets 3-4 fps both when the loading screen starts and after the loading is done the performance is just as bad. I seem to remember trying it with an older version of Wine about 3 years ago and it worked much better but unfortunately i don't remember which version or what commit may have broken it. Tried compiling wine for a regression test but the application won't start with the compiled version. I've attached the output of a WINEDEBUG=warn+all log below. Thanks for the help. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47767 iodreamify(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Ubuntu Version|unspecified |4.15 Hardware|x86 |x86-64 URL| |https://airport-mania-first | |-flight.en.softonic.com/ -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47767 iodreamify(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Airport Mania First Flight |Airport Mania First Flight |- Very slow loading times |- Very long loading times |and awful performance |and awful performance -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47767 iodreamify(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |performance -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47767 Paul Gofman <gofmanp(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp(a)gmail.com --- Comment #1 from Paul Gofman <gofmanp(a)gmail.com> --- I have tested the game trial. The immediate workaround to get the speed to normal is to disable CSMT (set HKCU\\Software\\Wine\\Direct3D\\csmt to 0). The other workaround is to set process affinity for AirportMania.RWG process after the game is started to default, like 'taskset -p 0xffffffff <pid>', where pid is process id of 'AirportMania.RWG' process which game creates. This will help if there is more than one CPU core present. Yet another workaround is set WINED3D_CS_SPIN_COUNT to 0 in dlls/wined3d/wined3d_private.h. The game sets process affinity mask to 1 for the process. Here are related calls (all that relates to process 'AirportMania.RWG', which is started from game launcher): --- 002c:Call KERNEL32.GetProcessAffinityMask(ffffffff,0032fad8,0032fac0) ret=00477314 002c:Ret KERNEL32.GetProcessAffinityMask() retval=00000001 ret=00477314 002c:Call KERNEL32.SetProcessAffinityMask(ffffffff,00000001) ret=0047744d 002c:Ret KERNEL32.SetProcessAffinityMask() retval=00000001 ret=0047744d 002c:Call KERNEL32.SetThreadAffinityMask(00000114,0000003e) ret=00477480 002c:Ret KERNEL32.SetThreadAffinityMask() retval=00000000 ret=00477480 --- I have no idea what the game is trying to achieve by its inventive thread affinity masks, but I verified that process affinity mask end up being 1 both under Wine and Windows 7, so that process is bound to a single logical CPU. Having done that, the game constantly locks and unlocks ddraw7 surfaces, that's the main load it creates. The most of the CPU spent in wined3d_cs_run() in CS thread, which is spinning waiting for task to be queued. Mapping of surfaces has to go through map queue, and also spins waiting while the CS thread does the actual mapping. Those spins create enough load for an effective single core execution to leave a very little time for anything else. Removing spin locking in wined3d_cs_run() (going to wined3d_cs_wait_event() every time) gets normal performance (while this is not a general improvement to CS thread locking logic of course). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47767 --- Comment #2 from iodreamify(a)gmail.com --- Wow, thank you very much for the quick response! I can confirm the first two workarounds work, good speed seems to be restored. I will not pretend to understand much of your deeper analysis there for the culprit so I'd just like to ask, is there any chance of a proper fix within Wine or is this solely the game's fault? Should this be closed? Thanks. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47767 --- Comment #3 from Paul Gofman <gofmanp(a)gmail.com> --- (In reply to iodreamify from comment #2)
... so I'd just like to ask, is there any chance of a proper fix within Wine or is this solely the game's fault? Should this be closed? Thanks.
This looks like a valid bug, I am not aware of any reason to close it yet and I hope this will be fixed sooner or later. Besides, while this game exhibits some ultimate case, that spin locking around CS thread in wined3d can affect performance in much more applications. Probably in any case when the game performance is CPU bound. Even if the game is not using all the available cores while being CPU bound, and we can have a core absolutely free to spin in CS thread, it is still harmful for performance for the following reasons: - spinning in lock involves memory access and memory fences (implicit on x86, but they are still there), which slows down the memory access for other cores or CPUs; - a common practice on today's desktop CPUs is to utilize heavy overclocking on the busy core(s). But this is not symmetric, in often can't overclock all the cores at the same time, or maybe it can for some time, but in any case will have to throttle CPU clock back as heat goes up. I think similar issue came up before, but there is probably no good and quick solution. I think just always using mutex (or similar) instead of going for long spin locks would be better. But as far as I understand it is currently a no go to use native host sync primitives in Wine DLLs (for various reasons). Using the Windows API ones is a no go too as currently all blocking waits end up in wineserver calls and it is worse for a general case (with this game being an exception). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47767 Daniel Perelman <dap56(a)cornell.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dap56(a)cornell.edu --- Comment #4 from Daniel Perelman <dap56(a)cornell.edu> --- The same workaround helped on Artemis Spaceship Bridge Simulator ( https://appdb.winehq.org/objectManager.php?sClass=application&iId=12465 ), although the bug wasn't causing noticeable slowdown, it just caused 100% CPU usage for a game that uses ~3% CPU on Windows. (With the workaround, it is still at ~40% CPU usage.) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47767 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #5 from Zeb Figura <z.figura12(a)gmail.com> --- Can you please retest with current Wine? This was likely addressed by f032ccc2715a5525601f741337a7bc7df6873c9d. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47767 --- Comment #6 from iodreamify(a)gmail.com --- Can confirm, it's fixed now. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47767 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |f032ccc2715a5525601f741337a | |7bc7df6873c9d Component|-unknown |d3d Resolution|--- |FIXED --- Comment #7 from Zeb Figura <z.figura12(a)gmail.com> --- Thanks, marking fixed then. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47767 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #8 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 8.19. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla