[Bug 52393] New: Sacred 2 Gold: Textures largely missing since 5.0-rc3
https://bugs.winehq.org/show_bug.cgi?id=52393 Bug ID: 52393 Summary: Sacred 2 Gold: Textures largely missing since 5.0-rc3 Product: Wine Version: 6.23 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: labre(a)posteo.de Distribution: --- Created attachment 71619 --> https://bugs.winehq.org/attachment.cgi?id=71619 main menu without background textures I found a driver and gpu independent regression, which apparently affects just Sacred 2 Gold (installer from GOG). Tested GPUs were AMD RX 5500XT (NAVI14) with AmdVLK as well as RADV, Nvidia Quadro M2000M with nvidia and Intel HD Graphics 520 (Skylake) with ANV. Regression symptoms include the missing background tree in the main menu, a blackscreen in singleplayer and missing non-plane textures in multiplayer (no movement control however).
From the Protondb reports I figured, that this worked originally on at least Intel and Nvidia, so I started looking for a regression since the reported wine versions.
Bisected this to f99d307a3e1f9beb7fd9dc8892b5cfabbabf816b # first bad commit: [f99d307a3e1f9beb7fd9dc8892b5cfabbabf816b] msvcrt: Use parse_double for scanf floats. -- 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=52393 labre(a)posteo.de changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #71619|main menu without |bisect log description|background textures | -- 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=52393 --- Comment #1 from labre(a)posteo.de --- Created attachment 71620 --> https://bugs.winehq.org/attachment.cgi?id=71620 Main menu since regression commit -- 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=52393 --- Comment #2 from labre(a)posteo.de --- Created attachment 71621 --> https://bugs.winehq.org/attachment.cgi?id=71621 Multiplayer start since regression commit -- 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=52393 --- Comment #3 from labre(a)posteo.de --- Created attachment 71622 --> https://bugs.winehq.org/attachment.cgi?id=71622 Main menu in last good commit -- 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=52393 --- Comment #4 from labre(a)posteo.de --- Created attachment 71623 --> https://bugs.winehq.org/attachment.cgi?id=71623 Multiplayer start in last good commit -- 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=52393 --- Comment #5 from labre(a)posteo.de --- Unfortunately I could not get it to run without DXVK, but besides that, it’s pure wine (well, with Lutris runtime). -- 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=52393 labre(a)posteo.de changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://www.protondb.com/ap | |p/225640 --- Comment #6 from labre(a)posteo.de --- Many of the reports in ProtonDB are related to missing PhysX, but a few are suspecting their drivers and describing the same symptoms. As said, they are occurring on all drivers for the three main vendors however. Some of those are: https://www.protondb.com/app/225640#cZiEsAQGJf https://www.protondb.com/app/225640#9TGvCuCRiB https://www.protondb.com/app/225640#Yahn76ETHd -- 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=52393 Henri Verbeet <hverbeet(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Component|-unknown |msvcrt Regression SHA1| |f99d307a3e1f9beb7fd9dc8892b | |5cfabbabf816b --- Comment #7 from Henri Verbeet <hverbeet(a)gmail.com> --- (In reply to labre from comment #5)
Unfortunately I could not get it to run without DXVK, but besides that, it’s pure wine (well, with Lutris runtime).
I think this game used to work with upstream Wine. (And the AppDB appears to confirm that.) If it really doesn't, perhaps that's another regression. I notice your bisection log starts at Wine 5.0, and you entered 6.23 for the reported version. Did you also try this with the current wine-7.0-rc5 version? -- 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=52393 Piotr Caban <piotr.caban(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban(a)gmail.com --- Comment #8 from Piotr Caban <piotr.caban(a)gmail.com> --- While running the game without dxvk I had to install d3dx9_36 to avoid a crash. I'm not able to reproduce the missing textures problem both with dxvk and with native d3dx9_36. -- 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=52393 --- Comment #9 from Piotr Caban <piotr.caban(a)gmail.com> --- Please attach a log with "msvcrt" debug channel enabled. While collecting the log, please quit the game as soon as menu with missing textures is displayed. -- 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=52393 --- Comment #10 from labre(a)posteo.de --- (In reply to Henri Verbeet from comment #7)
(In reply to labre from comment #5)
Unfortunately I could not get it to run without DXVK, but besides that, it’s pure wine (well, with Lutris runtime).
I think this game used to work with upstream Wine. (And the AppDB appears to confirm that.) If it really doesn't, perhaps that's another regression. Nope, it starts with d3dx9_36. Thanks for the hint @Piotr. I notice your bisection log starts at Wine 5.0, and you entered 6.23 for the reported version. Did you also try this with the current wine-7.0-rc5 version? Not yet, but I’ll try it on the weekend.
-- 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=52393 --- Comment #11 from labre(a)posteo.de --- Created attachment 71631 --> https://bugs.winehq.org/attachment.cgi?id=71631 Msvcrt debug log; compressed to stay in limit boundaries Got it to run with d3dx9_36. However the bug is still reproducible for me. Attaching the msvcrt debug log compressed for size reasons. Sysinfo: Gentoo amd64/hardened. GCC:8.5.0 -pie -hardened ssp These old Wine versions would not compile otherwise. On: Thinkpad P50 (Nvidia) Thinkpad T460 (intel) Custom desktop with Bulldozer era APU+RX5500XT (AMD) -- 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=52393 --- Comment #12 from Piotr Caban <piotr.caban(a)gmail.com> --- It looks like scanf is working correctly in all calls from the log (I've checked that native msvcr80 returns the same values as wine in all cases from the log). Could you please confirm that regression test was done correctly (e.g. by running the game with git head set to f99d307a3e1f9beb7fd9dc8892b5cfabbabf816b and f99d307a3e1f9beb7fd9dc8892b5cfabbabf816b^)? -- 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=52393 labre(a)posteo.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|6.23 |5.0-rc3 -- 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=52393 --- Comment #13 from labre(a)posteo.de --- Yes, I can confirm that. wine --version gives me 5.0-rc3-22-g66c9c358ae5c # good 5.0-rc3-23-gf99d307a3e1f # bad I also recreated the prefix from scratch with wine-vanilla-6.23, because 4.21/5.0 could not install physx. I created a win32 prefix for 2.65.1 and a win64 prefix for 2.65.2 + community patch and it is reproducible in both. Used winetricks vcrun2005 physx d3dx9_36 win7 to set them up. I also tried gcc-10, but unfortunately there were a few toolchain related regressions in 5.0. The first version, which the Gentoo toolchain team supported again, is 5.4. So I’m still compiling with gcc-8.5.0. If my toolchain setup would be horribly wrong however, I probably could not reproduce it with the lutris builds of 4.21 and 5.0. I could provide the compiled binary packages (generic x64/32), if that helps and I can post external links to, say, box.com, here. I’ve created a diff of the msvcrt log from both versions, which I will attach 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=52393 labre(a)posteo.de changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #71631|0 |1 is obsolete| | --- Comment #14 from labre(a)posteo.de --- Created attachment 71651 --> https://bugs.winehq.org/attachment.cgi?id=71651 msvcrt log of the bad commit -- 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=52393 --- Comment #15 from labre(a)posteo.de --- Created attachment 71652 --> https://bugs.winehq.org/attachment.cgi?id=71652 msvcrt log of the good commit -- 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=52393 --- Comment #16 from labre(a)posteo.de --- Created attachment 71653 --> https://bugs.winehq.org/attachment.cgi?id=71653 diff of both logs -- 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=52393 --- Comment #17 from labre(a)posteo.de --- Created attachment 71654 --> https://bugs.winehq.org/attachment.cgi?id=71654 warn+fixme channels for both versions Just checked the warn+fixme log and I get a lot of GLSL warning stuff, mentioning vs_out[n] possibly being used before initialization. Do you also get these? I’m getting these in both versions however. I’m currently testing with the Nvidia Quadro M2000M from the P50. Mesa is 21.2.6 with nvidia-drivers 470.94. The msvcrt logs were also captured with this system. -- 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=52393 --- Comment #18 from labre(a)posteo.de --- Forgot to mention that I also tested with yesterday’s git HEAD, although I lost the specific commit. Unfortunately it’s also reproducible with it. -- 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=52393 labre(a)posteo.de changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Gentoo -- 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=52393 --- Comment #19 from Piotr Caban <piotr.caban(a)gmail.com> --- Created attachment 71665 --> https://bugs.winehq.org/attachment.cgi?id=71665 part of regression commit that modifies parse_double function I still can't see anything wrong in results returned by scanf. The patch also makes some changes to parse_double helper, maybe the regression is caused by it. While reading C:\\users\\manu\\AppData\\Local\\Ascaron Entertainment\\Sacred 2\\options.txt file volume_group01 value is different between good and bad log (68 in good log and 69 in bad log (on my machine it's always 68)). I have no clue if this file changes between runs. Could you please try the attached patch applied on top of 66c9c358ae5c? I wonder if this change already breaks the game. -- 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=52393 --- Comment #20 from labre(a)posteo.de --- (In reply to Piotr Caban from comment #19)
Could you please try the attached patch applied on top of 66c9c358ae5c? I wonder if this change already breaks the game. Sure, but I forgot my external system drive, so I get to this as early as this weekend.
-- 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=52393 --- Comment #21 from labre(a)posteo.de ---
Could you please try the attached patch applied on top of 66c9c358ae5c? I wonder if this change already breaks the game.
I applied the patch and it does not break the game. Has to be something else. -- 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=52393 --- Comment #22 from labre(a)posteo.de --- Created attachment 71712 --> https://bugs.winehq.org/attachment.cgi?id=71712 Fixing patch against regression commit Hm, I strongly suspect, that make_double/fpnum_double returns infinity due to some unexpected or invalid double format, which might be given by the game, leading to the textures being misplaced, well, by infinity. The major difference made by the commit is, that the _control87 call is removed, which allows most likely invalid double formats or maths operations. Moving this call into the function and reverting it before any returns fixes this bug. It’s still odd, that you can’t reproduce it. At first I thought the decimal separator might be the difference, because my locale (de_DE.utf8) uses comma, however setting LC_ALL=en_US.utf8 in environment or registry did not make a difference, even when installing the English version of the game. What version of GCC/C library are you using and what is your locale? I’m currently compiling wine-vanilla-7.0 with the ported version of the patch. Let’s see, whether it works. -- 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=52393 --- Comment #23 from labre(a)posteo.de --- Created attachment 71715 --> https://bugs.winehq.org/attachment.cgi?id=71715 Port attempt to 7.0 non-working Nope, not working. Tried to guess the functions, which could be based on make_double, but even my bruteforce approach is not working. Some traces should be inserted to find the root problem, especially to find infinity returns, which might be wrong. -- 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=52393 --- Comment #24 from Piotr Caban <piotr.caban(a)gmail.com> --- (In reply to labre from comment #22)
Created attachment 71712 [details] Fixing patch against regression commit
There are few problems with attached patch: fpcontrol = _control87(0, 0); _control87(MSVCRT__EM_DENORMAL|MSVCRT__EM_INVALID|MSVCRT__EM_ZERODIVIDE |MSVCRT__EM_OVERFLOW|MSVCRT__EM_UNDERFLOW|MSVCRT__EM_INEXACT, 0xffffffff); if (!m) return sign * 0.0; You're not restoring fp control word in m==0 case. if (exp < -(1<<EXP_BITS)) { if (err) *err = MSVCRT_ERANGE; result = sign * 0.0; _control87(fpcontrol, 0xffffffff); } You have removed return sign * 0.0 in this if statement. The patch is removing the _control87 calls because it's no longer needed. The conversion is done using integers. All floating operations were removed except of sign*0.0 and sign*INFINITY (and none of this calls depends on fp control word value). Maybe it will be cleaner to change it to something like (sign == 1 ? 0.0 : -0.0) and (sign == 1 ? INFINITY : -INFINITY) but it shouldn't matter. -- 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=52393 labre(a)posteo.de changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #71712|0 |1 is obsolete| | --- Comment #25 from labre(a)posteo.de --- Created attachment 71730 --> https://bugs.winehq.org/attachment.cgi?id=71730 Fixing patch against regression commit -- 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=52393 --- Comment #26 from labre(a)posteo.de --- (In reply to Piotr Caban from comment #24)
(In reply to labre from comment #22)
Created attachment 71712 [details] Fixing patch against regression commit
There are few problems with attached patch: Addressed the problems and it still works.
The patch is removing the _control87 calls because it's no longer needed. The conversion is done using integers. All floating operations were removed except of sign*0.0 and sign*INFINITY (and none of this calls depends on fp control word value). Maybe it will be cleaner to change it to something like (sign == 1 ? 0.0 : -0.0) and (sign == 1 ? INFINITY : -INFINITY) but it shouldn't matter. I agree, that it shouldn’t matter, but at least in this commit it apparently does. In wine-7.0 however it does indeed make no difference. Of course it has been a long time since the regression commit. I probably could also bisect the commit, which introduced that.
-- 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=52393 --- Comment #27 from Piotr Caban <piotr.caban(a)gmail.com> --- Created attachment 71736 --> https://bugs.winehq.org/attachment.cgi?id=71736 float scanf tests with 24-bit precision and status word check Could you please attach output of msvcr90_test.exe compiled with attached patch (applied on top of current wine)? The patch adds some tests for +-0, +-INFINITY and random float while using 24-bit precision (the game uses 24-bit precision mode). Here's output on my machine: msvcr90.c:2370: 0 (0) msvcr90.c:2374: 80000000 (0) msvcr90.c:2378: 7f800000 (5) msvcr90.c:2382: 7f800000 (0) msvcr90.c:2386: ff800000 (5) msvcr90.c:2390: ff800000 (0) msvcr90.c:2394: 43a313b6 (1) 0020:msvcr90: 82 tests executed (0 marked as todo, 0 failures), 0 skipped. -- 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=52393 --- Comment #28 from Piotr Caban <piotr.caban(a)gmail.com> --- Created attachment 71737 --> https://bugs.winehq.org/attachment.cgi?id=71737 another approach on setting control word befory every operation on floats (In reply to labre from comment #25)
Created attachment 71730 [details] Fixing patch against regression commit You can also try the attached patch (to be applied on top of f99d307a3e1f9beb7fd9dc8892b5cfabbabf816b). Is it still fixing the regression? Is yes, it should be possible to find what part of the patch fixes it by commenting some control87 calls.
Taking in account what's in the logs I guess that: result = *((double*)&bits); assignment is causing problems. Could you please attach msvcrt.dll (or msvcrt.dll.so in case of no-mingw build) from your build? -- 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=52393 --- Comment #29 from labre(a)posteo.de --- (In reply to Piotr Caban from comment #27)
Created attachment 71736 [details] float scanf tests with 24-bit precision and status word check
Could you please attach output of msvcr90_test.exe compiled with attached patch (applied on top of current wine)? The patch adds some tests for +-0, +-INFINITY and random float while using 24-bit precision (the game uses 24-bit precision mode).
Here's output on my machine: msvcr90.c:2370: 0 (0) msvcr90.c:2374: 80000000 (0) msvcr90.c:2378: 7f800000 (5) msvcr90.c:2382: 7f800000 (0) msvcr90.c:2386: ff800000 (5) msvcr90.c:2390: ff800000 (0) msvcr90.c:2394: 43a313b6 (1) 0020:msvcr90: 82 tests executed (0 marked as todo, 0 failures), 0 skipped.
Okay, here is the output from patched wine-7.0 compiled with gcc-11; 64-bit prefix. msvcr90.c:2370: 0 (0) msvcr90.c:2374: 80000000 (0) msvcr90.c:2378: 7f800000 (5) msvcr90.c:2382: 7f800000 (0) msvcr90.c:2386: ff800000 (5) msvcr90.c:2390: ff800000 (0) msvcr90.c:2394: 43a313b6 (1) 00f4:msvcr90: 82 tests executed (0 marked as todo, 0 failures), 0 skipped. Seems to be the same, except for the last line prefix. -- 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=52393 --- Comment #30 from labre(a)posteo.de --- Ah, okay. You used a 32 bit prefix, due to the game. msvcr90.c:2370: 0 (0) msvcr90.c:2374: 80000000 (0) msvcr90.c:2378: 7f800000 (5) msvcr90.c:2382: 7f800000 (0) msvcr90.c:2386: ff800000 (5) msvcr90.c:2390: ff800000 (0) msvcr90.c:2394: 43a313b6 (1) 0020:msvcr90: 82 tests executed (0 marked as todo, 0 failures), 0 skipped. 32-bit on my machine. -- 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=52393 --- Comment #31 from labre(a)posteo.de --- Created attachment 71739 --> https://bugs.winehq.org/attachment.cgi?id=71739 Fixing patch minimized So, we’re requiring this in sign * 0.0, if the mantissa is zero. Maybe sign becomes NaN. The trace wouldn’t catch this case. -- 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=52393 labre(a)posteo.de changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #71730|0 |1 is obsolete| | --- Comment #32 from labre(a)posteo.de --- Comment on attachment 71730 --> https://bugs.winehq.org/attachment.cgi?id=71730 Fixing patch against regression commit Obsoleted by minimized version -- 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=52393 --- Comment #33 from labre(a)posteo.de --- (In reply to labre from comment #31)
Created attachment 71739 [details] Fixing patch minimized
So, we’re requiring this in sign * 0.0, if the mantissa is zero. Maybe sign becomes NaN. The trace wouldn’t catch this case.
On the other hand, a TRACE("sign is %d", sign); before it shows, that it is always 1 or -1, as expected. Hm, I dunno… Have to sleep. -- 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=52393 --- Comment #34 from labre(a)posteo.de --- Tried a few things without success: – Returning 0.0 instead of sign * 0.0 does not fix it. – Result is the same between patched and unpatched.
TRACE("result is now %f", result) return result; gives zero differences after sort | uniq for both outputs.
– Had the assumption, that the code flow might be changed by a floating exception, e.g. not returning 0.0, but unpatched always emits traces before and after the calculation. So I’m not sure, what the _control87 function does, even after looking up the Microsoft docs. Is there a way to catch occurring floating exceptions with gdb? I have no experience with it, but I could find some tutorials. -- 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=52393 --- Comment #35 from Piotr Caban <piotr.caban(a)gmail.com> --- (In reply to labre from comment #34) > – Returning 0.0 instead of sign * 0.0 does not fix it. The game still works for me when 0.0 is returned (even so it's incorrect). > – Had the assumption, that the code flow might be changed by a floating > exception, e.g. not returning 0.0, but unpatched always emits traces before > and after the calculation. So I’m not sure, what the _control87 function > does, even after looking up the Microsoft docs. Is there a way to catch > occurring floating exceptions with gdb? I have no experience with it, but I > could find some tutorials. There are no floating point exceptions. First of all, 0.0 * (any integer) should not cause any exceptions. Also the game is already masking all floating point exceptions. The control87 call affects 2 things: - it may affect how compiler optimizes code - it changes precision mode You can try checking following things: - maybe adding _control87(0, 0) call is enough to make the bug gone - instead of changing whole control word you can try setting only the precision (_control87(_PC_64, _MCW_PC)), it's the only setting changed by the game - please upload msvcr80.dll (or msvcr80.dll.so in case of non-mingw build) from wine f99d307a3e1f9beb7fd9dc8892b5cfabbabf816b - change "return sign * 0.0" to "return sign==-1 ? -0.0 : 0.0" Are you using any non-standard compilation options or CPU specific optimizations? -- 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=52393 --- Comment #36 from labre(a)posteo.de --- Created attachment 71750 --> https://bugs.winehq.org/attachment.cgi?id=71750 msvcr80.dll.so from my unpatched regression commit build Sorry for forgetting that request. -- 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=52393 --- Comment #37 from labre(a)posteo.de ---
Are you using any non-standard compilation options or CPU specific optimizations?
x86_64-pc-linux-gnu-gcc -m32 -c -o isfinite.o /var/tmp/portage/app-emulation/wine-vanilla-9999/work/wine-9999/libs/port/isfinite.c \ -I. -I/var/tmp/portage/app-emulation/wine-vanilla-9999/work/wine-9999/libs/port -I../../include \ -I/var/tmp/portage/app-emulation/wine-vanilla-9999/work/wine-9999/include -D__WINESRC__ \ -D_REENTRANT -fno-PIC -Wall -pipe -fcf-protection=none -fno-stack-protector \ -fno-tree-loop-distribute-patterns -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body \ -Wignored-qualifiers -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \ -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op \ -fno-omit-frame-pointer -march=x86-64 -mtune=generic -O2 -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 This is what the portage ebuild generates. No custom-cflags or optimizations beyond -O2 on my behalf. # /etc/portage/make.conf/custom CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe" CXXFLAGS="${CFLAGS}" -- 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=52393 --- Comment #38 from labre(a)posteo.de ---
You can try checking following things: - maybe adding _control87(0, 0) call is enough to make the bug gone Nope, it wasn’t.
- instead of changing whole control word you can try setting only the precision (_control87(_PC_64, _MCW_PC)), it's the only setting changed by the game Nope, that did not help.
- change "return sign * 0.0" to "return sign==-1 ? -0.0 : 0.0" Did not 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=52393 --- Comment #39 from labre(a)posteo.de --- Created attachment 71751 --> https://bugs.winehq.org/attachment.cgi?id=71751 Patches used for the above testing. -- 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=52393 --- Comment #40 from labre(a)posteo.de --- Using -O0 instead of the default -O2 with custom-cflags USE flag does not fix it either. Here are the flags of that compilation. x86_64-pc-linux-gnu-gcc -m32 -c -o dllfunc.o /var/tmp/portage/app-emulation/wine-vanilla-9999/work/wine-9999/dll s/strmbase/dllfunc.c \ -I. -I/var/tmp/portage/app-emulation/wine-vanilla-9999/work/wine-9999/dlls/strmbase \ -I../../include -I/var/tmp/portage/app-emulation/wine-vanilla-9999/work/wine-9999/include \ -I/var/tmp/portage/app-emulation/wine-vanilla-9999/work/wine-9999/include/msvcrt -D__WINESRC__ \ -D_REENTRANT -fno-PIC -fno-builtin -fshort-wchar -Wall -pipe -fcf-protection=none \ -fno-stack-protector -fno-tree-loop-distribute-patterns -fno-strict-aliasing \ -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wno-packed-not-aligned \ -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla \ -Wwrite-strings -Wpointer-arith -Wlogical-op -fno-omit-frame-pointer -march=x86-64 -pipe -O0 -- 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=52393 --- Comment #41 from Piotr Caban <piotr.caban(a)gmail.com> --- Created attachment 71757 --> https://bugs.winehq.org/attachment.cgi?id=71757 patches to test I don't see anything wrong in your msvcr80 build. I'm attaching 2 patches generated on top of f99d307a3e1f9beb7fd9dc8892b5cfabbabf816b for testing: - first patch adds traces with x87/sse status and control words. Please attach console output while running the game with the patch (the game should fail to display menu textures with this patch). - second patch sets and resets control word in make_double function, it should have the same performance impact as the patch that fixes the issue, maybe it's a race -- 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=52393 --- Comment #42 from labre(a)posteo.de --- Created attachment 71761 --> https://bugs.winehq.org/attachment.cgi?id=71761 Debug output patched with test1. Assumed msvcrt debug channel. -- 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=52393 --- Comment #43 from labre(a)posteo.de ---
I don't see anything wrong in your msvcr80 build. Glad to hear that.
I'm attaching 2 patches generated on top of f99d307a3e1f9beb7fd9dc8892b5cfabbabf816b for testing: - first patch adds traces with x87/sse status and control words. Please attach console output while running the game with the patch (the game should fail to display menu textures with this patch). Hope this helps.
- second patch sets and resets control word in make_double function, it should have the same performance impact as the patch that fixes the issue, maybe it's a race Yes, that works.
-- 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=52393 --- Comment #44 from Piotr Caban <piotr.caban(a)gmail.com> --- It turns out that the problem is caused by MXCSR register value. In non working case, it's value is 0x108001f. On my machine it's always 0x8001f. The code for saving/restoring x87 was incorrect and was also changing MXCSR. It means that the regression commit fixed a bug that was allowing the application to run on your machine. I've tried setting MXCSR to 0x108001f as on your machine. It breaks menu background as on your screenshot. According to your logs MXCSR is not set to this value by msvcr* functions (probably the game uses ldmxcsr assembly instruction to set it). Anyway, in order to fix this bug, it will be needed to find what and why is setting MXCSR register. -- 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=52393 --- Comment #45 from Piotr Caban <piotr.caban(a)gmail.com> --- The 0x108001f value is not really mcxsr value, this is what _control87_2 returns (so it has _DN_FLUSH set). -- 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=52393 --- Comment #46 from labre(a)posteo.de --- (In reply to Piotr Caban from comment #44)
It turns out that the problem is caused by MXCSR register value. In non working case, it's value is 0x108001f. On my machine it's always 0x8001f. The code for saving/restoring x87 was incorrect and was also changing MXCSR. It means that the regression commit fixed a bug that was allowing the application to run on your machine. I’m not sure, what register means in this context. Are these variables declared with the 'register' keyword, which might end up in a processor register?
I've tried setting MXCSR to 0x108001f as on your machine. It breaks menu background as on your screenshot. Glad to hear, that you could reproduce it. :)
According to your logs MXCSR is not set to this value by msvcr* functions (probably the game uses ldmxcsr assembly instruction to set it). Anyway, in order to fix this bug, it will be needed to find what and why is setting MXCSR register. So, what are possible candidates for this? Are they limited to other wine components or could this be also driver/firmware/hardware related? Can I do anything to help with that?
-- 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=52393 --- Comment #47 from labre(a)posteo.de --- Oh, and might be helpful to have a minimal C program, which sets the keyword to the working value, both for mitigating the bug temporarily without performance impact and to see, whether and at which point something resets it. -- 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=52393 --- Comment #48 from Piotr Caban <piotr.caban(a)gmail.com> --- Created attachment 71824 --> https://bugs.winehq.org/attachment.cgi?id=71824 print mxcsr in relay traces The mxcsr register is set on process startup so it's not something that can be preset with another application. In order to fix the bug it will be needed to find what and why sets it to incorrect value. Probably the first step is to find why the game doesn't work in current wine (it works for me). You can try to find what patch is breaking it again after setting control word in scanf/make_double. Another option is to run with attached patch and WINEDEBUG=relay. The patch prints if _DN_FLUSH is set. The trace look like this: 002c:Call ntdll.NtQueryDefaultLocale(00000000,0031f41c) ret=7b02c3f2 mxcsr=0 After mxcsr is changed it will look like: 002c:Call ntdll.NtQueryDefaultLocale(00000000,0031f41c) ret=7b02c3f2 mxcsr=1 Hopefully it will help find what is setting the _DN_FLUSH flag. -- 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=52393 --- Comment #49 from labre(a)posteo.de --- (In reply to Piotr Caban from comment #48)
The mxcsr register is set on process startup so it's not something that can be preset with another application. In order to fix the bug it will be needed to find what and why sets it to incorrect value. Scraping my basic OS knowledge together, I figured this too in the meantime. Due to this being an illegal OS operation, it would cause a segmentation fault and because of that require an exploit to work; thus this is not an option.
Probably the first step is to find why the game doesn't work in current wine (it works for me). You can try to find what patch is breaking it again after setting control word in scanf/make_double. I’ll try bisecting with the _control86_2 patch after looking for openal related causes.
Another option is to run with attached patch and WINEDEBUG=relay. The patch prints if _DN_FLUSH is set. The trace look like this: 002c:Call ntdll.NtQueryDefaultLocale(00000000,0031f41c) ret=7b02c3f2 mxcsr=0 After mxcsr is changed it will look like: 002c:Call ntdll.NtQueryDefaultLocale(00000000,0031f41c) ret=7b02c3f2 mxcsr=1 Hopefully it will help find what is setting the _DN_FLUSH flag. Could be openal. 0009:Call openal32.alcGetString(00000000,00001013) ret=027d614d mxcsr=0 0009:Ret openal32.alcGetString() retval=f5cd7a58 ret=027d614d mxcsr=1 … 0009:Call openal32.alcOpenDevice(0032e590 "JACK Default") ret=027d6824 mxcsr=1 0009:Ret openal32.alcOpenDevice() retval=f3305010 ret=027d6824 mxcsr=1 Could be related to it trying to open a Jack device. I have no pulseaudio support. Also I’m using pipewire, so the Jack server is actually the Pipewire Jack emulation, which could imply, that pipewire sets it. I’ll try recompiling openal with pulseaudio support, which might cause other code paths in pipewire.
versions (revisions indicate ebuild fixes or build patches): pipewire-0.3.44-r1 openal-1.21.1-r2 -- 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=52393 --- Comment #50 from labre(a)posteo.de --- Created attachment 71825 --> https://bugs.winehq.org/attachment.cgi?id=71825 relay log at mxcsr switch with ±100 lines context Could not add the complete start, because it is still 14M with xz -9 compression. If you need more context lines, leave a note. -- 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=52393 --- Comment #51 from labre(a)posteo.de --- So this was obviously caused by the default portaudio backend of openal, which tries to use a Jack Audio device, probably in combination with pipewire, but since pipewire is an external process, it can’t set the flag. Possibly its library sets it or openal itself. The workaround is to set #~/.config/alsoft.conf [General] drivers="alsa,-jack,-oss,-port,-null,-wave," -- 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=52393 --- Comment #52 from labre(a)posteo.de --- Note: this also works in current wine-7.1 including wine-staging. -- 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=52393 labre(a)posteo.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTOURBUG --- Comment #53 from labre(a)posteo.de --- Note 2: Had a DXVK crash bug after the game loading screen (singleplayer or multiplayer) with resolutions above 1080p, which has been fixed in 1.9.4. -- 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