Need For Speed Carbon crashes instantly when gallium nine is enabled

[ghost]

NFSCarbon crashes instantly, and wine shows this text

I'm on Fedora 32, with Wine-staging 5.9, kernel 5.6.15, win32 prefix, Mesa 20.0.7 I've tested GTA San Andreas and the game runs perfectly stable.

[dhewg]

The paste site doesn't work atm, can you please add the log here in a code block (starts and ends with three backticks, see also the "M" help icon on the edit box)

[dungeon007]

I replicated this weird issue, it works with wine default opengl wrapper or via dxvk/vulkan, just crashes instantly on start with gallium nine. Just to note how this seems to fail depending how mesa is compiled. Fail on CFLAGS if '-mfpmath=sse' is there and if not - it works.

[dungeon007]

I mean it specifically fails here if nine, so "d3dadapter9.so" is compiled with -mfpmath=sse 🤣

[dungeon007]

Not sure how to ping devs, but lets try... ping @dhewg @axeldavy

[axeldavy]

Do the dxvk and the ogl wrapper work with that sse flag ?

[dungeon007]

Yeah, no problem with a flag on this game, if i start the game with dxvk/radv or opengl. Just nine if compiled with a flag crashes this game on start. To bisect it i used -Dbuildtype=plain to build Mesa and then adding/removing flags manually on CFLAGS, CXXFLAGS... and whenever i put -mfpmath=sse on CFLAGS this game just crashes on start with nine only. And if i removed it from there, nine also stop crashing on start and works OK with a game.

[dungeon007]

BTW i tried 1.4 version of the game... but now i see Demo (v1.2) of the game shows the same bug: https://archive.org/details/DemosNeedForSpeedCarbon So, yeah it should be easy if you wanna test/debug this and mesa/nine build flags 🤣

[dungeon007]

Today tried demos of NFS games before (Most Wanted) and after (Pro Street) Carbon... and seems only Carbon is affected by this. Game probably just checks for some CPU instruction in a weird way and made this bug with nine.

[dungeon007]

I mean this is kind of distro specific bug, here Fedora bug as they build it "-march=i686 -mtune=generic" but also with sse path "-msse2 -mfpmath=sse". And then of course, if some distro does not force this, then bug isnt there... Debian, for example, dont force this so bug isnt there. 🤣

[axeldavy]

Possibly fixed by https://github.com/iXit/Mesa-3D/commit/0638a02d62cb400878c568a79d05ced8653042b7

[dungeon007]

Seems Carbon demo now works with csmt_force off, but does not with on.

Previosly both on or off were crashing.

[dungeon007]

I mean, build is Fedora-style with -msse2 -mfpmath=sse -mstackrealign... Without mfpmath=sse, both csmt on or off works. With mfpmath=sse and without patch both csmt on or off crashes. With mfpmath=sse and with patch, csmt on crashing like before and csmt off working. So i guess, just csmt somehow isnt aware of this. 🤣

[dungeon007]

BTW, seems like many many else apps seems stop working with this patch... so forget about it 🤣

[dungeon007]

@axeldavy Well, maybe you can forget about this bug, in terms of compilation flags... as it seems happens just with this app anyway. 🤣

[dungeon007]

@axeldavy And now guess what? 🤣 Native msvcr71.dll override makes it working with nine compiled with -mfpmath=sse... None else needed that override, but nine do, now that is interesting 🤣

[dungeon007]

Broken WINE's dlls, my gosh... what a BS.

[dungeon007]

Confirmed on Carbon demo 1.2 and 1.4 versions... WINEDLLOVERRIDES="msvcr71=n" which is shipped in a game folder makes it starting, if nine is compiled with -mfpmath=sse.

[dungeon007]

I mean not that patch needed "Possibly fixed by iXit/Mesa-3D@0638a02" just override to native msvcr71.dll

[dungeon007]

Only that could be a fan for users, if it happens elsewhere like that... compile mesa like this and not override needed, compile mesa like that and override nedeed. Anyway, nothing new that WINE do need overrides here and there, so 🤣

[dungeon007]

BTW, just saw that SSE thread... that is funny too, as there is nothing of else for 32bit other than SSE2 or SSE3. SSSE3, SSE4.x, AVX1, etc... these do nothing on 32bit. And since SSE3 seems gives nearly nothing over SSE2 on 32bit, that is an only sexy option anyway that makes some sense to jump to... but then again that sexy one seems frequently broken during development 🤣 I remember 2 years ago, i had to disable asm when compiling mesa to gain speed from these flags... i think Anholt was changing that, so didnt tried recently. I wont be surprised if it does not work again by default correctly, just by changing flags. 🤣

[dhewg]

Is this fixed now when using mesa v21.1.0-rc1 or later?

[dungeon007]

"Is this fixed now when using mesa v21.1.0-rc1 or later?" In a way fixed, in a way it isnt fixed, depends how you compile it 🤣 Default does not work if mfpmath is there... but there are workarounds like either:

0. compile mesa without -mfpmath=sse
1. csmt_force=0
2. override msvcr71 to native
3. patch wine's msvcrt to remove that sse2_enabled check or watch bugs like this for potentional fixes or some else workarounds https://bugs.winehq.org/show_bug.cgi?id=27594

[dungeon007]

In a way dunno what to think, as that kind of isnt a bug to me, esspecially if dll that works is shipped (as it is) in a game folder. Should we work with every borked WINE dlls on every WINE version? Probably not. 🤣