Final Fantasy XIV - Stutter since DXVK 0.54

[Hekel1989]

This is my first issue reporting on github, so apologies if it's not as precise as it's expected to be.

I've been using WINE+DXVK for a while now to play Final Fantasy XIV, and since DXVK 0.54, FPS went up, but the game now stutters a lot. It seems like the larger the area, the bigger the stutter. I've tried all version after 0.53 (0.5,.0.60,0.61,0.62 and 0.63 now) and they all present the same problem. If i revert to 0.53, the stuttering disappears.

I've tried with many WINE (Staging,PBA,ESYNC,Main) and the issue remains; It seems to be fully DXVK dependent.

I run the DX11 client, and it seems to happen regardless of the ingame settings (although the stutter is not as perceivable if i keep everything on low).

I've got Force Composition Pipeline enabled, but even if I disable it it doesn't change (and it didn't cause any issue before 0.54).

Software information

Env Vars: __GL_SHADER_DISK_CACHE GL_SHADER_DISK_CACHE_PATH GL_THREADED_OPTIMIZATION

Env Vars that I've tested after 0.54 to try to rectify: WINEESYNC __GL_SYNC_TO_VBLANK PBA_CB_HEAP PBA_GEO_HEAP

System information

-OS: Ubuntu 18.04 LTS

• GPU:Nvidia GTX 1080
• Driver: various (currently using 396.45)
• Wine version: Many of them, currently running 3.10
• DXVK version: 0.63 (and every version since 0.54)

Hope I've provided enough info :)

[doitsujin]

If the problem was introduced between 0.53 and 0.54, it should be easy for you to bisect the issue. Please do so.

[Hekel1989]

If you could guide me in how to narrow it down, that'd be much appreciated.

I tried everything within my (limited) knowledge, and I coudln't find anything that would fix it.

[doitsujin]

https://git-scm.com/docs/git-bisect

[varris1]

If you use staging & are able to compile it yourself, try to exclude the server-send_hardware_message patchset. It causes a lot of camera jitter in the game. It may be the "stutter" you describe.

[Hekel1989]

@varris1 not that stutter, it's not the mouse jittery effect (which i figured was cause by staging wine), it's proper stutter :)

@doitsujin cheers mate, I'll have a good read and try to bisect it :)

[Rotscha]

If I had to guess, I'd say it's because of the integrated shader cache, that was removed with 0.54. NVidia cache can only hold 128MB. Maybe not enough for the game.

[Hekel1989]

@doitsujin sorry mate, I've looked at a few tutorials online for git-bisect but I'm struggling a bit to carry on. So, do I have to mark 0.53 as good and 0.54 as bad? and that's all you need?

@Rotscha If it happens to be as you say, there's nothing that can be done?

[Hekel1989]

Ok, so, I'll copy and paste what I got from my terminal and you tell me if it makes any sense. I've searched for your 0.53 commit, marked it as good, then marked your 0.54 commit, marked it as bad, and then marked as bad any other step. Got no idea if I made any sense :)

~/test/dxvk$ git bisect start
~/test/dxvk$ git bisect good 8cd9795
~/test/dxvk$ git bisect bad 420b721
Bisecting: 17 revisions left to test after this (roughly 4 steps)
[4a0c81276fd59a9b3dddbaed1e554ee35a7104a3] [d3d11] Implement new auto-flush heuristic
~/test/dxvk$ git bisect bad
Bisecting: 7 revisions left to test after this (roughly 3 steps)
[621aed5fdbaf92764944be7b3a27cbb3df63ba94] [dxbc] Bound-check dynamically indexed constant buffer reads
~/test/dxvk$ git bisect bad
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[a9eff13b920c65ec020fbf170514731980efefc1] [dxvk] Refactor memory allocator
~/test/dxvk$ git bisect bad
Bisecting: 1 revision left to test after this (roughly 1 step)
[e615fc19a91891828919e0029d73cec77553636a] [dxgi] Support SyncInterval values > 1
~/test/dxvk$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[f68bf1a1874ab571df8c33d4716adbb575516a3d] [dxvk] Added correct element size to depth-only and stencil-only formats
~/test/dxvk$ git bisect bad
f68bf1a1874ab571df8c33d4716adbb575516a3d is the first bad commit
commit f68bf1a1874ab571df8c33d4716adbb575516a3d
Author: Philip Rebohle <philip.rebohle@tu-dortmund.de>
Date:   Mon May 28 20:33:49 2018 +0200

    [dxvk] Added correct element size to depth-only and stencil-only formats

    Fixes depth-to-color image copies in Elex and Neptunia VII.

:040000 040000 ed727e4c90dfe2babe8b38d4e2e723a614152bff 6112f602a5aa1a056a3ff9a16d05289672ac915e M  src

[Guy1524]

@Hekel1989 You are supposed to actually test whether the commit is good or bad. After you specify the good and bad commits, compile DXVK and test whether the stutter is present, then, if it is, use git bisect bad, and vice versa. Once you do this, test again and repeat.

[Rotscha]

Ah, i was wrong. Shader cache was removed with 0.42 already. So the issue is somewhere else. Sorry.

[Hekel1989]

@Guy1524 Thanks, but I tested them(I thought)? I mean, I've used every version since 0.52, I've tried them all on FF14, and 0.52 and 0.53 were fine, since 0.54 it started stuttering. So I marked 0.53 as good and everything else as bad, as I've tested them all already.

Isn't that the way it should be?

[Guy1524]

@Hekel1989 You did not, you wrote git bisect bad regardless of whether the commit was good or bad.

Heres the deal, there are many commits (think of them like subversions) between 0.53 and 0.54. Using git bisect uses a binary search tree to find which one causes the issue. When you give git bisect it's boundaries by specifying 0.53 as good and 0.54 as bad, then it will take you through multiple commits to find the breaking commit.

Please read my first comment again, it explains that you must compile DXVK after each search (git bisect good or git bisect bad command). Test DXVK, then mark that commit as git bisect good or git bisect bad.

[bobwya]

omg 8-/

[Hekel1989]

@Guy1524 Thanks, much clearer now :) Can I abuse your goodwill and ask if you could very briefly explain how to compile (or even send me to a link where can I learn it)? I'm very new to the Linux world(to me it all started with DXVK 0.52, so we're literally talking a couple of months) and I want to get involved and help if I can, but I'm very much inexperienced yet.

@bobwya Really not helpful and uncalled for mate, especially when I said in my first sentence this was the first time I've ever done this.

[Guy1524]

@Hekel1989 It depends on what distro you are on, but the compilation instructions are in the main README of the project

[Hekel1989]

@Guy1524 Thanks, I'm on Ubuntu 18.04 LTS, I'll give it a good read now and see if I can figure it out :)

[Guy1524]

Although you are on an older version of GCC, you should be fine for an older version like 0.53-0.54

[SveSop]

18.04 uses latest gcc (or 8.1 atleast). But you must setup a few things, explained on the dxvk main page @Hekel1989

Have not reviewed the git tree from .53 - 0.54, but git-bisect is not all that fool-proof in finding exactly a commit if there has been tree merges and such inbetween.

However easily explained (atleast in my eyes), lets take the following example. 0.54 = Bad Then you mark 0.53 as "good". Lets say there is 10 commits made between 0.53 and 0.54. If each commit would have been labeled with a release, it would be 0.53, then 0.53.1, 0.53.2 and so on. When you do git-bisect and compile each "version" like that, you will end up with (hopefully) that eg. 0.53.6 is the first one causing the stuttering, and this would be the problem, but as the other posts say, you have to compile and test each version :)

Atleast gives you something to do i guess.

[Hekel1989]

@SveSop Thanks Sve, that's very useful to know :)

I didn't have time the past days to go through it unfortunately. But I've still got a bit of an update regardless.

So, I've been fiddling around a bit more, and I managed to reduce the issue by 90%.

I've disabled Force Pipeline Composition in the Nvidia Drivers and set the game to render to in Fullscreen (windowed) rather than Fullscreen, with Vsync disabled.

For some reason, with all of these changed, there's some tearing now (bearable), but the stuttering literally dropped by 90%. there's a tad left, but it's really really mild.

Again, those settings have been used since DXVK 0.52 and it all change starting from 0.54; Maybe this can give a bit of a clue about what it is?

I shall update again once I manage to compile all versions and bisect them.

[freehaha]

I have been using dxvk for ffxiv since 0.41 and currently 0.63. I've experience two stutter issues before:

1. CPU(intel pstate) scaling keep changing. Once i set governor to "performance" this goes away
2. Ran out of vram because another application is also using a good chunk of vram. you can check the usage of vram using nvidia-smi and close applications if necessary.

other than that dxvk works pretty well for me for ffxiv. Hunts, 24man, raids are all smooth (dropping to ~40fps on heavy load, 55-60 otherwise) spec:

• GTX 960 2G w/ 396.24.10 vsync, allow flipping, no forced pipeline composition
• i5-6500
• wine 3.12 staging + esync + pba
• linux kernel 4.17 (previously 4.16)

[Hekel1989]

@freehaha Mind if i ask what do you use to change you cpu governor? I use a gnome extension, and it seems to do the job, but I'm happy to try different means.

Regarding the VRAM, I haven't checked, but having a GTX1080 i've got 8gb worth of it, and the game at top usage uses 3.5gb, so that shouldn't be an issue.

In your stats you said you're allowing flipping? mind explaining what that is? Also, with wine staging, don't you get that weird mouse jitter? I haven't updated my Kernel to 4.17, wouldn't know if that contributes.

Thanks for your input :)

[freehaha]

i use cpufreq-set to set the governor.

cpufreq-set -c 0 -g performance
cpufreq-set -c 1 -g performance
...

As for the 'allow flipping' option in nvidia setting I have no idea what it does but it doesn't affect my fps on or off. I've seen people having trouble with this option on in particular driver versions but on my side I didn't notice any major difference.

For the jitter issue in staging, I compiled wine myself excluding the server-send_hardware_message patch like mentioned above.

[SveSop]

@Hekel1989 @freehaha Or use: for i in $(seq 0 7); do cpufreq-set -c $i -g performance; done

Dont know if its actually needed to do it in a "per core" kind of way like that, but i do it to make sure tho :) Adjust (seq 0 7) based on number of cores tho.

For Ubuntu distro's: The cpufreq-set command is part of the cpufrequtils package. Install with sudo apt-get install cpufrequtils Also you need to run cpufreq-set as root with sudo aswell. Like this: for i in $(seq 0 7); do sudo cpufreq-set -c $i -g performance; done

[debiangamer]

The CPU governor is an optional feature of the Linux kernel and slows down your system. Most distributions use slow 300Hz debug kernels. Make a custom non debug 1000Hz timer kernel and remove unneeded features from the kernel. Use the Bios control the CPU and fans. For me, FFXIV Demo runs just fine at 4K with latest drivers. System: Host: ryzenpc Kernel: 5.0.0-rc1 x86_64 bits: 64 Desktop: Xfce 4.12.4 Distro: Debian GNU/Linux buster/sid Machine: Type: Desktop Mobo: ASUSTeK model: PRIME B350M-K v: Rev X.0x serial: UEFI [Legacy]: American Megatrends v: 4207 date: 12/07/2018 CPU: 6-Core: AMD Ryzen 5 1600 type: MT MCP speed: 3031 MHz Graphics: Device-1: AMD Ellesmere [Radeon RX 470/480] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.3 driver: amdgpu resolution: 3840x2160~60Hz OpenGL: renderer: Radeon RX 570 Series (POLARIS10 DRM 3.27.0 5.0.0-rc1 LLVM 7.0.1) v: 4.5 Mesa 19.0.0-devel (git-2b876bc 2019-01-12 cosmic-oibaf-ppa)

[Tk-Glitch]

No.

[ghost]

Apologies for necro commening but dont want to create a new thread. I might have similar issue with Final Fantasy XIV. Using dxvk up to 0.96 gives rock solid 60+ fps. When I switched to 1.0 and later 1.0.1, fps constantly kept changing between 35-60 and giving occasional performance issues. I'm using the latest nvidia vulkan drivers (arch) and wine-staging-esync (tkg) version. Is anyone experiencing similar for dxvk 1.0+ ?

[doitsujin]

I tested the Stormblood benchmark and it stays above 60 FPS pretty much all the time, not sure what's going on there.

[ghost]

Created a new clean wineprefix but the behavior is the same as I wrote before. Is there any kind of information, logs I can share?

[aaronmaslen]

@eproxy I still have occasional stutter (and weird camera movement), but performance was greatly improved by installing a newer version of mesa (19.1 or later). This obviously only applies to mesa drivers (ie. not nvidia), of course.

[doitsujin]

The game itself works extremely well on latest Proton with no wonky mouse movement for me. Closing since there really doesn't seem to be a DXVK issue here.