Limiting fps via MangoHud breaks the Hitman 3 engine (partially); corrupted and/or flashing textures, loading times

[CPioGH2002]

Describe the bug
The fps limit being enforced via MangoHud (as opposed to let's say using VSync) causes the Hitman 3 game engine to partially break and produce corrupted textures and flashing texture updates and/or shader application. It also leads to huge loading times (minutes instead of a few seconds) on an otherwise very fast system (in terms of loading performance). Once you toggle the fps limit off or use other means of limiting them, the engine behaves normal again and also loads very fast.

I don't think that Mangohud causes this issue but simply exposes it. I'm looking for tips as to what the actual cause could be and why it developed only lately.

Also, this worked fine just a few days ago and seemed to have been introduced by updates on other graphic related modules. The game wasn't updated, MangoHud wasn't, Nvidia drivers maybe were but reverting back to older ones also showed this behaviour.

List relevant hardware/software information

• Linux Distribution: Kubuntu 23.04 Edit: Now 23.10
• MangoHud version: 0.6.9-1 Edit: Now 0.7.0 - default config file only introducing the fps limit, no other settings
• GPU: RTX 2080 Super - 535.86.05 driver, but also tried with later 535.104.05 one
• Edit: GPU now RTX 4070Ti Super - 550.40.07 driver
• CPU: AMD Ryzen 7700X
• RAM: 32GB DDR6000, CL30
• SSD: Gen4 PCI-E (should load quickly and does so, once no MH fps limit is active)

To Reproduce
Steps to reproduce the behaviour:

1. Enable MangoHud config to set a defined fps limit, I've used 60fps
2. Make sure you can toggle mentioned limit on and off, so that the game engine is able to work "restricted" and "free" by your commands
3. Observe difference in loading times and also texture "streaming" behaviour between those two modes. Also note how (point) light sources sometimes get corrupted in the restricted mode. This affects camera cones (which become almost solid) and certain light sources which suddenly turn into rainbow colours instead of single colour.
4. Reload a level without leaving the game or changing any setting but just toggle your (MangoHud) fps limit off. Textures and light sources will be fine again.
5. Try to use other means of limiting the fps, e.g. via VSync which also causes no trouble for the game engine and produces correct textures and light sources.

Expected behaviour
The fps limit via MangoHud should of course limit the fps, perhaps even affect loading times (since some game engines behave that way) but it should not cause the texture streaming to bug out of even cause texture corruption.

Screenshots
I will add screenshot of the corrupted camera cone as an example. Have to check how to upload a video showing the "flashing" textures in actions. Turns out, they are not flashing, the game simply loads the wrong ones at some point and quickly changes them, hence the "flashing" impression.

Camera cones: (same game session, just loading the level without and with fps limit via MH)
How they should look like (=no MH fps limit active): https://abload.de/img/unlimitedhfijc.png
How they look with active MH fps limit: https://abload.de/img/limitedaff4h.png

Pairs of shots from the intro video while fps were limited, so textures "flashed" in a particular way:
https://abload.de/img/lim1h7eyw.png
https://abload.de/img/lim26hcru.png
https://abload.de/img/lim3qni2e.png
https://abload.de/img/lim4oki5z.png
https://abload.de/img/lim51ni5m.png
https://abload.de/img/lim6idch9.png

Seems like wrong textures appear at some point, without transition, hence the flashing impression while the game is running. Expect these changed textures to appear suddenly and also get reverted back quickly, except when it comes to mentioned camera cones and some light sources, which stay corrupted (for lack of a better term).

Note:
Please don't mind the horrendous latency graph on those shots. My video software used to record the game caused this and, without it, the game runs extremely smooth and well above 60fps if desired. Since the game runs completely fine without the MH-based fps limit and also performs well in other games, the appearance of this being a hardware issue is just that, a first (but wrong) impression.

Additional context
To repeat, I don't think this is actually caused by MangoHud. A few days ago, it couldn't even be made to show since everything worked as expected. I just like to get some tips as to which component might have caused this behaviour to arise. I did try other Nvidia driver versions but those didn't change things.

Workaround
My current workaround is to limit via VSync, so nothing is lost in terms of gaming. I would just like to receive some tips as to why this issue came up lately and does not seem to affect other games so far. Not that I tried many, but I did of course check if my hardware is ok and also how MangoHud works in other titles, which it does.

Thanks for developing this vital tool for us Linux gamers. :-)

Other references:
Not quite the same, but this somehow felt related in terms of symptoms and potential origins: #1106

[CPioGH2002]

Still present with 0.7.0. I wonder what makes the engine behave like that since the sheer 60 fps limit imposed by other means (like VSync) does not break it.

[flightlessmango]

I don't think this is a mangohud bug but rather a bug in the game engine

[CPioGH2002]

Valid point and I was thinking the same but since I can limit the fps by other means without causing the problems shown, I was wondering what special mangohud sauce might cause the game engine to fail in this particular manner.

I think I pointed out before that I don't view mangohud as faulty in any way but it remains interesting to find out why only mangohud leads to such symptoms. The symptoms themselves are interesting since one would assume all kinds of problems like a game not even starting with mangohud active or something. But this case is different and it wasn't obvious at first that the sheer presence and active fps limit were to blame.

So maybe there's something to learn from how this "Glacier" engine handles, in case the problem comes up more often. Since it isn't used very often, it may remain an exception.

PS:
Sorry for my late answer. I forgot to set email notifiers.

[err0r2k]

The same problem happen with libstrangle.

[CPioGH2002]

Thanks for the info. Means the game engine, as expected, is to blame. Still remains a strange issue but, as it seems, none which can be solved by Mangohud but only worked around by using other means of limiting the fps.

[flightlessmango]

If it doesn't happen on windows, it's possible it's a wine bug

[err0r2k]

If it doesn't happen on windows, it's possible it's a wine bug

Will try it out on Windows with the Nvidia frame limiter.

[CPioGH2002]

If it doesn't happen on windows, it's possible it's a wine bug

It doesn't happen on Linux if one uses V-Sync to limit at say 60Hz. Wouldn't that rule out a Wine bug?

[err0r2k]

If it doesn't happen on windows, it's possible it's a wine bug

Will try it out on Windows with the Nvidia frame limiter.

Test System:
Windows 10 22H2 & Linux Mint 21.3 (Ubuntu22.04)
RTX2080 (Mobile)
144 Hz Screen with G-Sync
VSync On

Game Settings:
VSync Off
FullScreen
1920x1080
DLSS - Quality
HDR - Off

Tested with MIAMI Level

Windows Frame Limiter 60 FPS (NV Driver 551.52):
NVIDIA - no Problems
RivaTuner - no Problems

Linux Frame Limiter 60 FPS (NV Driver 535.154.05):
MangoHUD - Acess to Main Menu, loading a level result in infinite loading, toggling frame limit after loading the level result into strange and broken gameplay with flickering
LibStrangle - Acess to Main Menu, loading a level result in infinite loading

[CPioGH2002]

Nice testing. If you like to, add the VSync test to Linux by temporarily setting your screen to say 60Hz, enabling VSync in the game and therefore receiving 60fps without any issues on Linux.

[err0r2k]

Nice testing. If you like to, add the VSync test to Linux by temporarily setting your screen to say 60Hz, enabling VSync in the game and therefore receiving 60fps without any issues on Linux.

Yeah, this will work. But when you turn on VSync ingame, Gsync will not work correctly and you will get the little Vsync stutter.
Is there maybe a parameter or option where you can start the game with 60Hz?

Other solution is setting Screen to 144Hz, Vsync ingame off and limiting the GPU Power with e.g.: sudo nvidia-smi -lgc 1000,1000
So you will get the FPS over 60 but not too much FPS because of limiting the GPU Power and Gsync works.

So is it a wine bug? Where can we open an issue?

[CPioGH2002]

Good points on the VSync downsides. I must admit, I don't notice them much, if at all. Speaks for my insensitivity I guess. I'm not a gamer, just a casual user in that sense.

Well, the whole VSync excursion served another purpose though: If the game does not show the symptoms described above (first post) when being limited by a "hard" VSync limit, can we really draw the conclusion of there being a Wine-related bug?

We are at this state: (assuming a 60 fps limit for testing, on Linux)
1) limiting via Mangohud or libstrangle --> Game engine errors
2) limiting via VSync --> no game engine errors
3) running unlimited --> no game engine errors

If we would assume a problem with Wine, it must be something that is triggered only in the first case described.

Forgot to add:
Since this was opened a while ago, my system from the initial post changed to Kubuntu 23.10 and the graphics to a RTX 4070Ti Super with the proprietary 550.40.07 driver. The results are the same however, which goes to show the generic nature of the problem.

[err0r2k]

One more idea because we are both NVIDIA user. Maybe, this is an NVIDIA related problem?

[CPioGH2002]

Well, if it is, it's not a general one as the game itself works and can even be limited in fps but, sure, if an AMD user would test the case, it would add valuable data to the pool.

Forgot to add:
Intel Arc users on Linux would also be welcome. Any of those three. :-)

[err0r2k]

Some guy in the www tested it with a AMD GPU.
Works fine for me on 7800xt and Mangohud FPS limit: https://i.imgur.com/uyLYWsa.png

[Tanza3D]

same issue with an rtx 3060 ti

[CPioGH2002]

As the Issue is still open, here are my current findings:

• First of all, this is NOT a Mangohud issue
• Second: Since I tried with multiple Mangohud versions and also changed the Nvidia driver all the while the game still received updates, one can attest that neither of those factors plays a role as the errors remained in place
• Third: Which leads us to the remaining element: The runner in use. In my case, I always went with what Lutris (where the EPIC Games launcher is run through) offered, so I had "wine-ge" or older Proton versions in use. Since this is/was the config leading to errors, I always went with my VSync-based workaround explained above.

Now I recently tried these two runners and used Mangohud to limit the fps again: GE-Proton9-21 and Proton9.0-4.
Turns out that neither of them has or produces any issues when Mangohud limits the fps. By this, we can assume that the older runners like "wine-ge" (which, otherwise, is a very reliable candidate for older games) in conjunction with how the Hitman3 engine works caused the problem my OP describes.

In short: To solve the errors (long loading times, corrupted textures) Hitman3 produces when Mangohud limits the fps, simply use more updated runners like GE-Proton9-21 and Proton9.0-4.

After that, loading times might still take a slight hit (as it seems that's how the game engine works) but the graphics remain intact while also allowing for all game engine features like DLSS and ray tracing to get enabled. Later on, Nvidia folks might also be able to use frame generation as the menu item at least is active, albeit maybe not stable at this time.