I've not seen reports of this happening on Windows. How do I identify calls to CreateShader?

Shader compilation related stuttering usually only occurs once for every new effect/material/area of the game you encounter, and will be gone once those shaders are cached. So you can usually identify it just by running repeatedly through the same area of the game, if it only stutters the first time, it's usually shader compilation stutter. You can also enable the full DXVK hud and look if the shader/pipeline counter going up coincides with the stutters.

However, I would also at least try the game with wine-staging or a proton-based wine build with esync or fsync, poor performance or stutters are not necessarily D3D related always, and vanilla wine has known bottlenecks with multithreaded games.

It doesn't seem to be related to shader compiling. While yes, it gets triggered once in a while, the stutters continue even if the counter doesn't go up or the "Compiling shaders..." message on the bottom left doesn't appear. I also tested Wine staging 9.19, with the same results, very noticeable when the game is running at 160 no-vsync, less noticeable when activating vsync and 60, but still happening on both. I move by dodging with the character, this produces a feather behind me.

I'm using the bottom of the elevator hallway that leads to the first mayor area/boss (Estate of the Urn Witch) which has no cloud cover/effect and is pretty small with not many elements. Using default visuals (aberration, etc.).

I also tested Wine staging 9.19, with the same results

You also need to set WINEESYNC=1 to enable esync.

You also need to set WINEESYNC=1 to enable esync.

I was using fsync already, I use it by default. I tried esync expecting the same results, but that didn't happen. Esync shows no frame pacing issues, even on the scenarios that were problematic before. With 1440p@165 no-vsync, the hallway, hub world, and further into the Estate all only cause stutters when shaders were being compiled, unlike before where stutters would happen regardless.

What does this mean? I was under the impression that fsync was the preferred solution if the system supports it.

·Where do you get the fsync patches for wine from and does that also reproduce when running the game with proton+fsync? I don't know what causes it but if it's a problem with fsync it should be reported on the proton github.

You asked to use wine staging, so that's what I'm using. I am using upstream binary distribution. There isn't "xsync: up and running" message outside of the patched versions/proton.

Upstream wine or wine-staging don't support fsync though, so how were you using it?

I don't think esync/fsync will every be in upstream wine because they are apparently incorrect in some edge cases, ntsync is supposed to be an upstream solution eventually.

So i take it that the issue only exists with upstream wine server sync and esync (and presumably also fsync) fixes it? If so, you can close this issue. Performance problems without esync/fsync are to be expected.

Since wine staging won't tell you you are using esync unless you use WINEDEBUG=+esync anyways, I didn't bother to actually check.

Wine staging actually only includes the e-sync patches and NOT also f-sync. It never had both, just e-sync.

P.S.: You still need to enable it via WINEESYNC=1, btw.