Cannot lauch Diablo 4 stream ver with Msync +GPTK

[suservu123]

With Crossover and whisky i can run diablo 4 by rename dstorage.dll to dstorageold.dll in folder game. But it just can lauch with Esync + GPTK. Even though i used newest whisky was update newest Msync patch for battel.net player

[MysticalOS]

Was just gonna add, https://github.com/marzent/wine-msync/issues/5 is also still an issue. just tested with crossover 23.7 but with msync patched by cxpatcher, the fix didn't work for me at least.

[marzent]

Hm just double checked again with the official 23.7 source + the patch and it was fine for me, maybe something else is causing an issue there?

[suservu123]

I tested again and still can't open Diablo 4 with msync + GPTK

[suservu123]

but with Wined3d work with msync but have some error and crash the game

[MysticalOS]

Same for me on bnet. using D3DMetal and Msync just cause a hung diablo4.exe process to appear but no game ever appears. Happy to log if I figure out how :D

[hgustafsson]

Related issue: https://github.com/Whisky-App/Whisky/issues/507

[MysticalOS]

The gist I got reading that other ticket is. Prior to the latest code changes, msync worked in whisky/wine 7, but wine 8 it was broken. the code change somehow fixed it in wine 8/crossover but not for everyone (cause it remained broken for me), but also additionally caused it to no longer work in wine 7 and whisky since pretty much all of those users universally say it got broken

Diablo 4 is a special snowflake indeed.

[marzent]

Alright, now the should definitely fix it this time... D3DMetal has some initialization code, where it checks for WINEESYNC and WINEFSYNC (don't ask me why) env vars. If these are not set, it will emulate synchronization for d3d event callbacks with dispatch semaphores, since server-side sync is so slow. Unfortunately it seems apple has made an implementation that is a bit racy here for D4. You can fix this though in any way you like (set WINEESYNC=1 and WINEMSYNC=1 together, binary edit D3DMetal and replace WINEFSYNC with WINEMSYNC, etc.)

[MysticalOS]

WIll you make fix available crossover 24? I've actually been testing the nightlies. using nightly to play D4 right now in fact. but i haven't tried toggling msync

[marzent]

Yeah should be fixed

[MysticalOS]

Will test in 2420240123

[MysticalOS]

Seems to work, msync seems to be improving performance and not crashing diablo

I guess crossover ignores esync if msync is also enabled, but it solves D3DMetal triggering race condition if it thinks esync is on? or does crossover 24 do some special handling for that as well?

[marzent]

Ah, the "automatic", fix is not in the nightlies yet, but yeah that is the gist of it, the way it works is that msync is currently stronger than esync; just out of curiosity, what is your setup and what difference are you seeing?

[MysticalOS]

M3 Max 40 core GPU, so I def hit cpu bottlenecks more often than gpu ones due to wine, unless I push 4k native.

For diablo specifically msync solves a few dips below 60fps at 4k using FSR 2 balanced. a few cpu bottlenecks even if gpu was only at 80-90%.

I may retest 120fps at 1080p later, i know when i tried it with esync it was massively cpu bottlenecked with gpu waiting for work.

[marzent]

but it solves D3DMetal triggering race condition if it thinks esync is on?

The race condition happens when D3DMetal thinks esync (or fsync) is not on. What races here is apples fallback implementation.

[marzent]

WIll you make fix available crossover 24? I've actually been testing the nightlies.

Actually most likely tomorrows nightly or beta 2, due to unfortunate timing

[marzent]

Well it seems it will be in beta 1 anyways, feel free to reopen this issue if it doesn’t fix itself automatically there.

[MysticalOS]

but it solves D3DMetal triggering race condition if it thinks esync is on?

The race condition happens when D3DMetal thinks esync (or fsync) is not on. What races here is apples fallback implementation.

Yeah that's understanding I got.

Actually makes me wonder how apples code works. So if environment esync is on, apple uses that instead of it's own implementation and that's why it avoids the race I assume, but does it stay on the esync path or can it actually use msync?

Or can apple actually benefit further from msync in D3DMetal? I'm basically curious if apple could be leveraging msync thesmelves, to further optimize D3DMetal

[MysticalOS]

Tested Beta 1, Msync works without needing to simultaneously enable esync too 💪

[marzent]

Awesome!

Actually makes me wonder how apples code works. So if environment esync is on, apple uses that instead of it's own implementation and that's why it avoids the race I assume, but does it stay on the esync path or can it actually use msync?

It takes the wine sync path, which ends up in either esync, msync, or sever-side sync; there is really nothing for apple to do here (well apart from detecting the env var correctly).