Arkham Knight All Over Again

This time I'm looking at an engine on the opposite extreme. It has a much too conservative resource ceiling for textures. The engine loads, then unloads and later reloads the same assets hundreds of thousands of times over the course of an hour. All the while, VRAM is only ever 25% filled on my GTX 1080 Ti and none of that nonsense is necessary.

I have limited control over this situation, which effectively calls for limiting the number of jobs in-flight per-frame. There's no such configuration parameter in this engine like there was in Arkham Knight. Thus, I have resorted to a little-used feature of Windows Vista+ known as Multimedia Class Scheduling to dynamically raise and lower the priority of threads performing the same or related tasks as system responsiveness changes. The scheduler achieves the necessary rate control in a round about way.

Two scheduler tunes exist

• Slow (for low-end hardware)
• Fast (for high-end hardware or people who don't mind stutter but hate texture pop-in)

I cannot easily make the scheduler tuning user-configurable since this all has to be setup immediately after threads announce their names to any attached debugger.

For best results, enable my framerate limiter and disable the game's.

This also fixes the game's flimsy anti-debug so any debugger or performance tool can be attached while the game is running without the game self-destructing. Attaching a debugger immediately at start-up still results in the game's suicide.

What lessons can we take away here?

Ubisoft needs to work on some kind of hysteresis and rate control in their resource manager; it is not DRM contrary to popular belief that causes high CPU load on PC, but insane driver overhead caused by really naïve resource management for such a vast open-world game.

It should be easily fixable. Clearly the dev. team focuses on consoles because there appears to be no consideration given to the significantly higher throughput of PC storage devices such as my NVMe SSDs in RAID0. The faster your disk is and the more CPU cores you have, the more of an unpredictable performance nightmare this all becomes.

    Thus, we have a repeat of Arkham Knight and nobody seems to have learned anything 🙄

To future port developers

Please actively limit disk throughput before it becomes a detriment to gameplay. Microsoft has even done the heavy lifting for you, open-world games are almost a textbook use-case for Multimedia Class Scheduling and Real-time Work Queues.

More details are available on my Steam forum post and I am more than happy to discuss all of this on the development section of the Special K Steam group.

EDIT: Most of this can be solved just by swapping the thread priority on the asynchronous file I/O completion thread with the one reading from disk.

The priority of the async thread is so high that it preempts the worker threads for trivial stuff that can wait 1-2 frames. Meanwhile, the thread that actually reads from the disk needs a priority boost or hitching happens frequently in cities.