Dark Souls 3: Unstable frame rate on macOS

[a-poptsov]

Frame rate of the game in a static scene is around 40-50(video setting/resolution almost don't affect it) but could be dropped to 20(or even lower in rare cases). CPU/GPU utilisation is not "criminal" in these cases

warn:  D3D11Device: Vertex input 'COLOR1' not defined by input layout
err:   D3D11: Cannot create texture:
err:     Format:  86
err:     Extent:  512x512x1
err:     Samples: 1
err:     Layers:  1
err:     Levels:  10
err:     Usage:   8
err:     Flags:   0

DarkSoulsIII_d3d11.log

Software information Dark Souls 3

System information Hardware: Macbook Pro M1 Max OS: 12.1 Crossover: 21.1 DXVK version: v1.9.3-mac-async https://github.com/marzent/dxvk/releases/tag/v1.9.3-mac

Related https://github.com/doitsujin/dxvk/issues/2442

[cdavis5e]

The CrossOver version of MoltenVK has a ton of hacks in it to make games like this run faster--or at all. (I oughtta know because I wrote many of them.) It's possible that one of these is interfering. You should really file a bug with CodeWeavers. The fixes we make sometimes find their way back here.

[cdavis5e]

Ah... thinking about this some more, based on your log, it looks like the culprit is our old nemesis, tessellation. Tessellation performs horrendously on Metal, due primarily to two factors:

• The need to save the output of the vertex and tess. control (hull) stages to buffers for consumption by the tess. evaluation (domain) stage. Buffers are much more expensive than the internal registers most implementations use, but we can't use those because of the unusual programming model tessellation has in Metal. Which brings us right to...
• The need to end the render pass to switch to compute to run the vertex and tess. control stages. On IMR GPUs, this isn't so bad, because they render directly to VRAM, but it's especially bad on TBDR GPUs like M1 because they render to an internal tile buffer, which is flushed every time the render pass ends. Much of the performance gain of TBDR is due to deferring this expensive flush to VRAM; the tessellation programming model in Metal, however, completely negates this.

There is unfortunately little I can do about this. I've already tried several things to speed up tessellation on Metal, to no avail. The one thing I haven't tried that might help is caching the output of the tess. control stage; that way, we pay the performance cost only once instead of every draw. But if VRAM pressure is high, the temporary buffers will likely be purged in order to make room, which will again require us to run the vertex and tessellation control stages, with everything that entails.

[Rithari]

Hi there,

It occurs to me that what you are describing is simply a general dip in performance, but making it overall still playable. Would this per chance also include the stutters that happen during autosave, which eventually translate into very frequent stutters which require a game restart to solve?

In any case, thank you for bringing this issue up here, unfortunately I lack the skills in regards to MoltenVK and game emulation on different architectures, but if I can help in any way I would be glad to do so, getting DS3 to run stutter-free, not necessarily at max frame rates is something I would definitely like to have.

@cdavis5e On a side-note: This might sound really out of place, but I suppose it is worth an ask. Since you are able to disable tessellation on AMD GPUs via their control panel, is it possible to disable this on an M1 SoC? Perhaps this would yield greater performance gains similarly to how it does for AMD pre 400-series GPUs.

[a-poptsov]

@cdavis5e I am appreciating your detailed explanation. Looks like caching might be a good option as it is widely used a lot in games like witcher 3 and performance of it is much better. I will report this issue to crossover as well for sure, but particularly this log is from the version of crossover that is using latest version of moltenVK and latest version dxvk(I haved replaced libraries to do the test)

[a-poptsov]

And just few words for the game in general:

1. I highly recommend for test to launch the game in window mode as it will allow to access graphic settings menu without any lags
2. Static scene fps is around 40-50 and almost doesn't depends on resolution and graphic settings and this is super weird. I am really curious what could cause this glass ceiling as CPU/GPU are far from 100%. As I mentioned before witcher 3 is scaling perfectly by the resolution(more or less stable 60 in 1080p and around 45 in macbook native resolution)
3. Looks like there is some room for optimisation in CPU as looks like most of the time the game is using just 2 cores
4. Crossover version of moltenvk has same issues as latest vanilla version of moltenvk

[a-poptsov]

1280x720 1440x810 1600x900 1680x945

[Rithari]

@a-poptsov Would you be able to confirm whether or not you have stutters whilst picking up items?

[a-poptsov]

@Rithari I will try to prepare better video with proper testing but as for now please have a look to https://www.twitch.tv/videos/1266022997 Please turn off the audio as it is too loud.

[Rithari]

@Rithari I will try to prepare better video with proper testing but as for now please have a look to https://www.twitch.tv/videos/1266022997

Please turn off the audio as it is too load.

Thank you. This confirms the auto-save stutter.

[a-poptsov]

I have tested the game little bit more and looks like @Rithari is right. I agree that FPS goes down during auto save process. So, I think, this issue should be split into two

1. FPS cannot go higher than 50; Even with low settings and 800x450 resolution
2. FPS goes down to 10-25 during save process (FYI: In this moment regular 210% cpu turns into 260% for the process)

@cdavis5e could you recommend how to handle these two. Should any of them stay on the plate of MoltenVK or both for Crossover team

[Rithari]

Hello all,

I'm pleased to report that I've successfully solved the stuttering in Dark Souls III. I'm not exactly sure what has solved it, so maybe someone else testing it may be able to help.

I've set d3d11 and dxgi to native for the CrossOver wine bottle due to an unrelated game fix-attempt and that seems to have lifted the frame-rate issues in this game. To test it out switch d3d11 from native, built-in to native and add dxgi as native under the library imports. I will update this comment with relevant findings within the next few hours.

Update:

The auto-save, menu usage and similar stuttering has been completely solved. However, the issue initially described here is still present; after a while, the game will stutter slightly and eventually turn into literal screen freezes of a few seconds ending with a disconnect due to bad frame-rate, as it decreases with every passing minute. I would assume this is due to the tessellation handling problem described above.

[a-poptsov]

@Rithari just for my curiosity, could you try to do the same but running the game in a window mode

[Rithari]

@Rithari just for my curiosity, could you try to do the same but running the game in a window mode

Apologies for the late reply, I was running all this in windowed mode.

[K0bin]

The stuttering might just be shader compilation.

[Rithari]

The stuttering might just be shader compilation.

Stuttering that gets increasingly worse? Pretty sure the shader compilation should finish at some point. Besides, it's fine in the beginning and only stutters after a while.

[a-poptsov]

@Rithari FYI: I did the same setup as you did with d3d11 and dxgi. The frame rate got more stable + start using experimental native build of obs to do recording. It is still far from perfect but most of the time it is in a range 30-40 fps; The good part is that I haven't experience degradation that you have described. Pls check https://www.twitch.tv/videos/1274736811 in case you are interested

[Rithari]

@Rithari FYI: I did the same setup as you did with d3d11 and dxgi. The frame rate got more stable + start using experimental native build of obs to do recording. It is still far from perfect but most of the time it is in a range 30-40 fps; The good part is that I haven't experience degradation that you have described. Pls check https://www.twitch.tv/videos/1274736811 in case you are interested

Hey there. Thank you for providing an update. I can see that in the entire hour of your stream you have not had any type of degradation, which is weird. I have stopped playing DS3 after their server maintenance as I finished it, however, I might soon try the game again and see if an update solved the issue or if it's still something with my machine.

I have also noticed that at some point my RAM usage was through the roof. I do not recall the exact situation but perhaps the game had been running for a few hours by that point in time. It's a weird memory leak that I haven't been able to reproduce to this extent, but I do notice an increase in RAM usage over time.

[a-poptsov]

@Rithari one difference is might be version of moltenvk. As for this bottle I am using latest from https://github.com/Gcenx/MoltenVK/releases/tag/v1.1.6

[luca-mattioli]

@Rithari Ciao! Can I ask you how did you manage to set d3d11 and dxgi to native for the CrossOver wine bottle? I've been looking in every file config but I didn't find it how to do it... Thanksss I want to remove that nasty stutter once for all

[cdavis5e]

@Rithari Ciao! Can I ask you how did you manage to set d3d11 and dxgi to native for the CrossOver wine bottle? I've been looking in every file config but I didn't find it how to do it... Thanksss I want to remove that nasty stutter once for all

The simplest way to use DXVK is to simply right click on the bottle, and under "Options," check "DXVK Backend for D3D11."

The simplest way to switch a DLL to native is to use the Wine Configuration program (winecfg). On the "Libraries" tab, you can set any DLL, including d3d11 and dxgi, to native.

All that does is set a registry key, HKCU\Software\Wine\DllOverrides, with value name equal to the basename of the DLL, type REG_SZ, and value n for native, or b for built-in. You use the Registry Editor (regedit) to make changes to the registry. Or you can change the file user.reg with a text editor.

[luca-mattioli]

Thank you so much! I edited everything via regedit since in the Library menù every time I edited them for some reason they didn't save the setting permanently. Anyway HUGE perfomance gains, that was amazing. I still need to figure it out what to improve more... Maybe changing graphical settings or I can try to see with or without e sync... Anyway when I found the best possible setting I will write a guide on Reddit since the site is scarce of these precious info.

[Pull4ward]

All that does is set a registry key, HKCU\Software\Wine\DllOverrides, with value name equal to the basename of the DLL, type REG_SZ, and value n for native, or b for built-in. You use the Registry Editor (regedit) to make changes to the registry. Or you can change the file user.reg with a text editor.

I am sorry for the question, but what exactly is meant by the "name equal to the basename of the DLL"? The name of the last folder in string (the "DllOverrides")?

[cdavis5e]

I am sorry for the question, but what exactly is meant by the "name equal to the basename of the DLL"?

In Windows (and DOS and OS/2) jargon, the basename is the part of the filename before the extension. So in, for example, d3d11.dll, the basename is d3d11. In a pathname (a filename with subdirectories), each directory named has a basename as well, but the basename of a pathname usually refers to the basename of the file at the end; e.g. for C:\WINDOWS\system32\d3d11.dll, the basename is still d3d11.

Registry keys can have multiple values associated with them. Each value has a name. You can see this if you were to open the Registry Editor.

[Pull4ward]

Registry keys can have multiple values associated with them. Each value has a name. You can see this if you were to open the Registry Editor.

understood, thank you very much