Anonymous edits have been disabled on the wiki. If you want to contribute please login or create an account.

Warning for game developers: PCGamingWiki staff members will only ever reach out to you using the official press@pcgamingwiki.com mail address.
Be aware of scammers claiming to be representatives or affiliates of PCGamingWiki who promise a PCGW page for a game key.

Topic on Talk:Grand Theft Auto IV

This is a permanent link to the first version of this post. You can view later versions on the post history page.

I did almost 6 hours test of various stream.ini settings on RGL version.
The most interesting results gave me:
virtual 102400
physical 409600
virtual_optimised 153600
physical_optimised 614400


Above, I went further with going with the scheme of better results when virtual value was set to be smaller than virtual_optimised, when it gave better results. A similar approach also seemed beneficial for physical memory.
Doing the opposite (smaller optimised value for virtual) gave worse results before.

It's pretty hard to get completely matching results in one pass in testing the same driving route, like I was doing, because traffic is pretty much random, and only weather remains more or less the same using the same save all the time. Benchmark is useless - average FPS is stupidly high and incomparable with results achieved in the heavy traffic. 2nd pass in benchmark always increases average FPS by ~1FPS.
So I also share settings I got good and better than stock results (204800 everywhere) out of many more tested if someone wants to experiment. Usually more than 1 pass for all settings used for tests.
virtual 102400, virtual_optimised, 153600, 614400 for both physical
614400 everywhere
409600 everywhere
default (204800 everywhere)
It still requires further testing since I couldn't use DSR/VSR this time to max out resolution, and I was stuck to FHD and max details. Used DXVK, ENB, Reshade, W10, 4 cores. Too low virtual memory set (e.g. 512 or even 512000) causes object disappearing (but 0 not, although decreases performance) hence it needs further testing for settings with virtual memory decreased. 102400 for virtual memory was a minimum value for FHD and maxed out details when there was no texture disappearing.

As for an influence on memory of these settings - it is minor. Depending on settings, RAM allocation difference is not bigger than 200MB.
The behavior is generally the same for all these settings (if only objects always appear).
The game can allocate up to 4GB of RAM, but when it's above 3900, it usually drops memory usage to around 3000MB, rarely with a freeze.
I was driving the wrong way on the highway for a long time to get faster memory allocation across the gameplay (in GTASA it was faster to fly by a Hydra to trigger memory related crash on big texture mods, but here I got only 3500MB max). When you press Print Screen, ENB+Reshade screenshots are being taken at the same time, and the memory usage usually jumps by 100MB, and then usually drop to 3K happens shortly afterwards, but the game itself also does it by itself, but rarely. Usually you won't get much above 3800MB (1.4GB used by the OS with the closed game, nothing really memory-consuming opened, 1.3GB used by the game process when minimised, but that value doesn't include pagefile). I never exceeded 9700MB for RAM and pagefile combined (memory compression on).
I have more than 4GB RAM, so it is not the system which limits the game from using more than 4GB in that case. It's 32 bit app limitation, and as someone checked headers in Visual Studio before, also patching the binary with Large Address Aware patch returns the same checksums as before, so it is already built-in with Large Address Aware in mind in vanilla game (RGL version was said to be the same as the others at some point)
Out of curiosity, I updated DXVK to 2.0 after getting the results above. Didn't do it before to avoid stuttering under specific circumstances described in 2.0 changelog, so no new cache wasn't needed to be rebuilt in such worst case. Old is almost 600KB, and new after one testing pass is 66KB. Not much.
Anyway, clean cache with 2.0 version provided the highest FPS in a certain place when I previously had maximum 47 (45-47) FPS. Few more. First time so much in that place.
Compared it with async version with async turned on in config, and it didn't get such an FPS neither with old nor new cache. Haven't experimented with dxvk.numasyncthreads yet. Tried out only maxFrameLatency = 1 which turned out to be beneficial, while VSync and triple buffering set in dxvk.conf wasn't, but actually prevented from one stutter, but I didn't perform additional pass to ensure it wasn't random.
Till the next time.