[d3d9] GTA IV Complete Edition stuttering

[moutorde]

GTA IV runs smoothly without stutters on version 1.8.1, once the state cache file has been properly made (after a bit of gameplay). On version 1.9, it seems to recompile the shaders at each session, resulting in high stuttering every time I start playing. Once the shaders have been compiled, the gameplay is smooth again as expected but the progress made (shader caching related) is lost if the game is exited. However, the state cache file is growing as normal. It just isn't "read" by DXVK, DXVK only writes on it.

The process of compiling the shaders (if it is what happens at each launch) is also very laggy. On version 1.8.1, with no state cache file, there are very small stutters that drop the framerate from 60 to 55 max during the process, it stays very playable. On version 1.9, it is unplayable during the first minutes, with a 4 fps gameplay and seconds of freeze. The "queue submissions" value easily goes above 280 when the stutters/freeze occur on v1.9, when it doesn't go above 30 on v1.8.1 even with an empty state cache file.

Software information

Game: Grand Theft Auto IV: The Complete Edition v1.2.0.43 Graphics API: DirectX 9 Architecture: x86

System information

• GPU: RTX 2060 SUPER
• Driver: 471.11
• DXVK version: 1.9
• OS: Windows 10 64-bit (1809)

Apitrace file(s)

• https://drive.google.com/file/d/1MRTE7e-f1cnJ5zGZxXUR1R3qPpPJgsgp/view?usp=sharing Wonder if it has any sense since it doesn't use d3d9.dll from DXVK v1.9?

Log files

• d3d9.log: https://drive.google.com/file/d/18B2zBti8wgRgAbTR0yfmQsfuFN-YdFZK/view?usp=sharing

[K0bin]

DXVK relies on the driver to cache the actual shaders. The state cache is only useful if the game actually tells DXVK to compile shaders in advance (ideally during loading screens).

So there's probably nothing wrong with DXVK here, the game just doesnt create its shaders in a way that the state cache can avoid stutter and the Nvidia driver decided to wipe the cache (maybe to make room for shaders of another game).

[raimonade]

Yep, exactly the same issue on RTX 2060 using 1.9, 1.8.1 runs perfectly.

[doitsujin]

From the log:

info: DXVK: Read 390 valid state cache entries

Looks like the state cache is working just fine, this doesn't really look like it's our bug.

[moutorde]

I was completely wrong indeed. State cache is not the issue here. It is VRAM allocation.

Using -managed launch option fixes the problem on v1.9. It is not needed on v1.8.1. Why, I don't know, maybe because of the incorrect VRAM value workaround that was implemented.

Thanks to this (see -managed GTA IV commandline.txt parameter) : http://ant-sh.blogspot.com/2020/07/gta-4-stutter-choppiness-fix.html

[doitsujin]

Does disabling the workaround manually help?

FWIW, we also know about an issue with increased memory usage in 1.9, unfortunately it's not exactly easy to fix without sacrificing performance.

[K0bin]

Current master shouldn't really have any problems with increased memory usage over 1.8.1.

[moutorde]

Does disabling the workaround manually help?

FWIW, we also know about an issue with increased memory usage in 1.9, unfortunately it's not exactly easy to fix without sacrificing performance.

Do you mean forcing dxgi.emulateUMA = False ? No it doesn't help.

[Markie98]

Same problem here. At first I managed to get past shader cache compilation with the Nvidia 466.77 drivers and the game became completely smooth, but then after restarting the game a few times it seemed to stutter again, going out of Niko's first safehouse. I thought it could be RAM related so I disabled the Steam overlay and it actually became smooth again. Then I realized I had the same problem going out of Luis Lopes' last safehouse in TBoGT even with the Steam overlay disabled, so I edited the RAM values that the games uses in Grand Theft Auto IV\GTAIV\pc\stream.ini (I changed all occurrences of "204800" to "409600") and it seemed to completely fix it, also allowing me to enable the Steam overlay back. The game was 100% smooth with the 466.77 drivers then. Later, I updated to the 471.11 drivers and it started doing the shader cache compilation stutters all over again, every single time, and this time the increasing RAM values nor disabling the Steam overlay helped it. The 471.41 drivers that have released yesterday have the same issue. Lastly, I tried creating a commandline.txt in GTA IV's .exe directory and adding "-managed" to it like @moutorde said and it's all finally fixed! VRAM usage is higher and most of it is filled up during loadings, which means they take noticeably longer, but on the other hand the game seems to behave properly with DXVK and the latest Nvidia drivers now.

[K0bin]

Please make an apitrace without the managed option.

I tried reproducing the problem but it's perfectly smooth for me. (or well, as smooth as GTA IV gets, the game is still a trainwreck)

[Markie98]

@K0bin Check what's written in this page about this "-managed" command. It's in the "-managed GTA IV commandline.txt parameter" section. I think this might be some useful information for you guys:

http://ant-sh.blogspot.com/2020/07/gta-4-stutter-choppiness-fix.html#_Toc45820772

[K0bin]

I know what it does but it shouldn't be necessary. The game runs very well for me without that.

[moutorde]

Please make an apitrace without the managed option.

I tried reproducing the problem but it's perfectly smooth for me. (or well, as smooth as GTA IV gets, the game is still a trainwreck)

Already done on first post. Isn't it usable ?

[K0bin]

Can you test if #2163 helps?

I can not reproduce the problem, it's basically perfectly smooth for me and never dips below 60 fps at highest settings, doing 14,000 draw calls.

[raimonade]

using -managed and bumping up the stream.ini values helped on my end.

[moutorde]

Can you test if #2163 helps?

I can not reproduce the problem, it's basically perfectly smooth for me and never dips below 60 fps at highest settings, doing 14,000 draw calls.

Using d3d9.dll from here https://github.com/doitsujin/dxvk/actions/runs/1046377684 (SHA1: 654AA51C435FC6D33781E226755E380B0B908E8E). Doesn't fix the issue.

On #2163 : Vidmem heap 0 : 1036MB usage in safehouse, progressively increasing to ~1200MB when going out and experiencing mad lags.

Same on release v1.9. -managed option makes this value ~1200MB inside safehouse, increasing to ~1300MB when going out (still seems a bit inconsistent but smooth).

v1.8.1 uses 830 MB in safehouse, increasing very fast to ~1000MB when going out (seems like stutter-free).

I am not experienced at all with these things so I'll probably say nonsense or use wrong terms here. The problem (if it is really a problem) seems to be in the moment when the VRAM gets allocated. Done very fast and almost stutter-free on v1.8.1, and done with very poor performance on v1.9. Only way to make v1.9 smooth is pre-allocating VRAM in during the loading time.

[K0bin]

Can you make a longer apitrace?

Any chance you can git bisect the issue?

Also: do you use any special launch options (when its stuttering) and are you copying over all DXVK dlls or just d3d9.dll?

[moutorde]

Any chance you can git bisect the issue?

The issue definitely appears starting commit f4cbc9a. Before this commit, the game launches with option d3d9.customVendorId = 1002. After this commit, the game launches without it, but adding dxgi.emulateUMA = True.

Starting the game without d3d9.customVendorId = 1002 is the reason why the lags appear (tested to run release v1.9 with this option forced in dxvk.conf and it runs as smooth as v1.8.1).

Of course you already know all about it and the last commit, 5037e49 gets d3d9.customVendorId = 1002 back. Starting this commit, the game runs as smooth as before commit f4cbc9a.

Now a downside of this is that d3d9.customVendorId = 1002 seems to annihilate dxgi.emulateUMA = True's effect. Before commit f4cbc9a, the game needs -availablevidmem=8192 launch option to detect my 8GB of VRAM instead of 512MB. Between commit f4cbc9a and commit 11bbc07 (included), the game doesn't need the launch option and automatically detects 8GB. Since commit 5037e49, the game only detects 512MB of VRAM but is smooth again.

I attached a little txt file to resume this, and the d3d9 logs from each commit.

Can you make a longer apitrace?

Do you still need a new longer apitrace? I followed this guide at first https://github.com/Joshua-Ashton/d9vk/wiki/Making-a-Trace and used the included d3d9.dll. The stuttering was like without d3d9.customVendorId = 1002 but I thought it might be just because it's a debugging program ?

Also: do you use any special launch options (when its stuttering) and are you copying over all DXVK dlls or just d3d9.dll?

When stuttering, no options are used. When it's smooth, i used -availablevidmem 8192 as explained before. I only copy d3d9.dll to the game folder (and dxvk.conf to easily toggle HUD when needed, but every option is #'d).

resume.txt GTAIV_d3d9 1.8.1.log GTAIV_d3d9 1.9.log GTAIV_d3d9 11bbc07.log GTAIV_d3d9 15e0594.log GTAIV_d3d9 5037e49.log GTAIV_d3d9 f4cbc9a.log

[K0bin]

The issue definitely appears starting commit f4cbc9a

I only copy d3d9.dll to the game folder

That's interesting. f4cbc9a does not do anything without dxgi.dll except that it accidently broke a workaround for GTA IV. The workaround pretends you have an AMD GPU in order to prevent the game from trying to use Nvidias NvAPI.dll because that's incompatible with DXVK. 5037e49 fixes that workaround. I assume the game uses NvAPI to read the available VRAM when it detects an Nvidia GPU which is why the VRAM was detected correctly when it was broken.

Nice to know that it's smooth again on master. You can try copying over dxgi.dll and see if that fixes the VRAM detection, if not just keep using the -availablevidmem launch option.

I'll consider this fixed.

[moutorde]

Alright, thanks for you help and the explanation. Just tried with dxgi.dll, it doesn't fix the issue. I'll just stick to using -availablevidmem launch option.