GPU hang in A Hat in Time on Vega 64

[Kiwii]

I'm running into a reproducible GPU freeze/hang when running A Hat in Time with Gallium Nine, in chapter 1, act 4, when going through a door into a bathroom with a reflective floor on the right side of the building at the beginning of the level.

The hang does not occur in Wine's d3d9 implementation, but performance without Nine is so bad that the game is not enjoyable.

I tried to record an apitrace, but the game seems to crash at the splash screen when I put the wrapper dll in place and set the environment variables as instructed by the wiki.
Edit: Here's the trace, see this comment

Gallium Nine Standalone: v0.4.0.294-release installed via "protontricks 253230 -q galliumnine" Mesa: 19.2.0-devel (git-fc455797c1) Linux: 5.1.2.arch1-1 Distro: Arch

GPU: Asus Radeon RX Vega 64 ROG Strix CPU: AMD Ryzen 5 1600

I have attached Xorg log, system info as reported by Steam, the log file created by Proton, and the journal filtered with "uniq -c", as there were thousands of duplicated lines.

Xorg.0.log
steam system info.txt
steam-253230.log
journal_deduped.txt

If this is not a Nine bug, I would appreciate a pointer to the appropriate place to report it.

EDIT: Upon further testing, I found the issue only occurs when "Dynamic Lights" is enabled in the advanced graphics settings (enabled by default in all graphics presets except for the lowest one).

[Francesco149]

i have the same problem, except when loading the subcon forest boss fight (chapter3, act6) . either skip or let the cutscene play. about when the boss is supposed to appear the whole system hangs. this also happens when doing death wishes that involve that boss.

this wasn't happening before the nyakuza update. not sure what happened

EDIT: I'm running a r9 270x btw

[ghost]

Also 100% reproducible with "Dynamic Lights" on, RX580 and mesa-git, on Chapter 1 Act 4, going into the bathroom, it locks up my game.

[axeldavy]

Would it be possible to get a trace of a scene supposed to hang (running under wine to prevent the hang) - check it hangs when replaying. https://github.com/iXit/wine-nine-standalone/wiki/apitrace I'll investigate whether the issue is nine or not.

EDIT: Please make sure antialiasing is not enabled when making the trace. Antialiasing makes debugging harder.

[ghost]

Hat in Time just crashes while trying to start it following those instructions. I see the splash screen and that's it.

I have this in Steam launch options

WINEDLLOVERRIDES=d3d9.dll=n,b WINEDEBUG=fixme-all,+debugstr TRACE_FILE=/home/user/d3d9.trace %command%

And that provided apitrace-msvc/x64/lib/wrappers/d3d9.dll file in the same directory as the Hat in Time binary HatinTime/Binaries/Win64

It did create a >100MB trace file in my home directory though, within the few seconds it tried starting.

[axeldavy]

That's unfortunate, apitrace doesn't work with some games.

The second option to debug this is to make a log with mesa built with ' -D b_ndebug=false' if using meson or --enable-debug if using autoconf.

Be sure to have a save prepared to trigger fast the hang in order to have short log.

Log can be made with R600_DEBUG=vs,ps NINE_DEBUG=all NINE_TGSI_DUMP=1 NINE_FF_DUMP=1 csmt_force=0 wine pathtoSteam.exe &> ~/mylog and launch the game from the opened steam.

[axeldavy]

It might be interesting to try the radeonsi nir backend as well

[Francesco149]

@z0z0z disconnect any joypad, it's what was making apitrace crash for me.

i managed to get a trace, it's gonna get a while to upload but ill let you know if it plays back without hangs in a bit

[Francesco149]

...and it does hang! as soon as the green stuff in the middle of the map is on screen. (chapter3, act6)

will upload the trace, it will take a while cause my upload speed is absymal

[axeldavy]

Thank you for taking the time to take this trace. Don't forget to compress it before upload, it can help with upload time.

[Kiwii]

After some fiddling, I got the game to not crash with apitrace by running it directly in Wine without Steam (apparently it's DRM free) with Wine's d3d9 and disconnecting my controller as recommended by Francesco.

I disabled all graphical effects except for the dynamic lights which is necessary to trigger the bug, and I capped fps at 30 to try to keep the file size small. Also this is without any DLC installed, as I don't own it.

So here's my trace for the chapter 1, act 4 bathroom hang. (700MiB, 1.6GiB unpacked)

It's on my own webspace, which should allow downloading with full speed. If there's any issue, I can reupload it wherever you'd like.

Playing it back with Nine does indeed hang my Vega 64; meanwhile it plays fine with Wine's d3d9 (except Wine has graphical errors and horrible framerate).

Also this was with mesa 19.0.4 (as opposed to mesa-git in the OP) and the behavior is identical. It also hangs regardless of Wine version (tested different proton builds, regular Wine and Staging from versions 4.2 through 4.8)

If there's any additional info that would help or if you'd like me to test different settings, please let me know.

[Francesco149]

ops, i kinda forgot i was uploading that apitrace

here it is: https://mega.nz/#!ZJhRhYaR!cVsMkRYkl6kPl0f43sMKu8NI4pvA4eE85cbLJyoQ-jE

this is with all dlc's installed and mesa-git

[orbea]

i have the same problem, except when loading the subcon forest boss fight (chapter3, act6)

I have seen most of the chapters in the subcon forest crash and or hang, removing my mesa shader cache sometimes helps and I suspect its a game bug given that I have seen threads indicating that some windows users are affected too.

[axeldavy]

I investigated the trace from Kiwii.

The game was crashing early due to llvm memory issues.

windows 32 bits apps can only do with 2GB of memory (unless special flag requested). Apitrace was too close to that 2GB it seems...

By default radeonsi compiles a first shader asm when requested, and compiles a more optimized one in the background. Thus several shaders can compile at the same time. I got the trace to bypass that memory issue with AMD_DEBUG=mono You probably are unaffected as the shaders are already compiled and in cache for you.

With AMD_DEBUG=mono, however, I didn't have any hang on my RX 480. I use llvm 8.0.0 and recent mesa.

Could you try it, just in case ? You can also try with csmt_force=0 which disables nine multithreading. radeonsi_enable_sisched=true will generate different shaders (different asm scheduler), so it may by chance help a buggy shader.

Basically see if that works: radeonsi_enable_sisched=true AMD_DEBUG=mono csmt_force=0

If not, as it replays fine here, it is a radeonsi bug (llvm ?)

[Francesco149]

about the memory issue - my trace is for the 64-bit version of the game so the 2GB limit shouldn't be a problem

radeonsi_enable_sisched=true AMD_DEBUG=mono csmt_force=0 does indeed fix the hang for me

[axeldavy]

Interesting it replays on 32bits apitrace :-) Which of those flags helps ?

[Kiwii]

My trace was also recorded from the x64 executable and I used x64 apitrace to play it back locally.

wine apitrace-msvc/x64/bin/apitrace.exe replay d3d9.trace

Now when I try to play my trace with those variables set:

radeonsi_enable_sisched=true AMD_DEBUG=mono csmt_force=0 wine apitrace-msvc/x64/bin/apitrace.exe replay d3d9.trace

It just crashes with "LLVM ERROR: ran out of registers during register allocation": https://pastebin.com/ij0vSFEn

[Francesco149]

AMD_DEBUG=mono is the flag that fixes the issues for me

[Francesco149]

note that my tests were done playing the actual game, not playing back the trace

[Kiwii]

With just AMD_DEBUG=mono set, my trace plays until it reaches the bathroom, then hangs the same way as when I play the game.

AMD_DEBUG=mono wine apitrace-msvc/x64/bin/apitrace.exe replay d3d9.trace

[axeldavy]

@Kiwii: that's probably radeonsi_enable_sisched=true and your version of llvm being unhappy with some shaders. Does AMD_DEBUG=mono fixes the issue for you as well ?

As the issue is a radeonsi bug, I suggest to file it here: https://bugzilla.freedesktop.org/ as a radeonsi mesa bug.

[Kiwii]

@axeldavy AMD_DEBUG=mono does not fix the issue for me; it hangs just like when I play the game normally.

[axeldavy]

Which llvm are you using ?

[Francesco149]

with AMD_DEBUG=mono the trace plays back fine for me. mesa-git and llvm-svn

[ghost]

Keep in mind Kiwii and Francesco are talking about two different places in the game that cause lock ups.

[Kiwii]

Which llvm are you using ?

Right now I'm using llvm 8.0.0; when I originally reported the bug, I ran llvm 9 from svn. I could go back and test my trace with mesa-git and llvm-svn if that would help?

I could also download Francesco's trace and see how it runs on my Vega but as z0z0z said, this seems to be two different issues, and it's starting to get a bit confusing who ran which combinations now.

[axeldavy]

I could replay both traces fine here with mono (same memory issue without. It's more convenient for me to run 32bits apitrace as I use my mesa nine debug build only on 32bits to not affect whole system, but I can check distro 64bits mesa if you think it helps)

[axeldavy]

In any case, whether there is one or two bugs here, there is at least one bug that seems to be radeonsi issue.

[Francesco149]

I reported my hang here: https://bugs.freedesktop.org/show_bug.cgi?id=110713

[Francesco149]

@Kiwii 's trace doesn't hang for me btw with AMD_DEBUG=mono

[Kiwii]

I've found the error of my ways. In mesa 19.0 the AMD_DEBUG alias doesn't exist yet, so I had to set R600_DEBUG=mono and voilà, both traces play fine. Same with AMD_DEBUG=mono on mesa-git + llvm-svn, both traces play without hang.

I will see if I can add any information to @Francesco149's bug against radeonsi.

In the meantime, I guess "R600_DEBUG=mono %command%" in Steam can be a workaround to play the game. Any idea if this will have a negative effect on performance or will it just increase loading times? (It feels to me all shaders are generated ahead of time when a new level is loaded, so I assume it will be fine?)

Thanks everyone for the time invested in researching the issue. It's much appreciated. And thanks for Gallium Nine in general!

[chewi]

I still need to get a trace but I've had the game freeze very frequently when changing hats, sometimes even requiring a reboot. AMD_DEBUG=mono makes the problem go away. I suspect it's a variation of this issue. I have an RX 480.

[chewi]

Still happens. Unfortunately both D9VK and AMD_DEBUG=mono are pretty sluggish by comparison.

[Venemo]

Can you please give us an API trace with which the problem can be reproduced?

[chewi]

I'm not sure if that's feasible because for me, it happens at random and can take an hour or more.

[chewi]

I got lucky and managed to capture a trace in the same place it froze last time. I'm not sure if it worked properly though. Is it normal to see lots of stuff like this during replay?

3205 @0 IDirect3DTexture9::UnlockRect(this = 0x7fed2400, Level = 0) = D3D_OK
3205: warning: unknown object 0x7fed2400
3206 @0 IDirect3DTexture9::LockRect(this = 0x7fed2400, Level = 1, pLockedRect = &{Pitch = 1024, pBits = 0x7fa401bf7040}, pRect = NULL, Flags = D3DLOCK_NOSYSLOCK) = D3D_OK
3206: warning: unknown object 0x7fed2400
warning: passing high address 0x7fa401bf7040 as uintptr_t
3207 @0 memcpy(dest = 0x7fa401bf7040, src = blob(131072), n = 131072) // fake
3207: warning: dest buffer overflow of 131072 bytes

[axeldavy]

Hi, where could this trace be found ?

As a side note, it's possible that the Hat in Time consumes a lot of RAM memory and is very very slow to load in recent mesa releases. I have worked on it and have a fix.

[orbea]

This occurs with d9vk too.

[lorn10]

And now follows a 2022 update to this topic. Right at the beginning it should be noted that I bought the GOG.COM version of "A Hat in Time" not the Steam one.

Good news, the original issue which was caused by the Dynamic Lights setting seems to be no longer present. :+1: This is true for an old iMac12,2 system containing a Radeon HD 6770M GPU and running Kubuntu 20.04 LTS, Wine 7.7 plus Mesa 22.2.0-devel (git-6bef59f 2022-04-24 focal-oibaf-ppa).

So I didn't notice really a difference between Dynamic Lights enabled or disabled. Lowering or disabling the anti-aliasing had more effect.

However, this doesn't mean that the game is running perfectly well. Yes, if you have patience, then it looks possible to play the game quite fine. But be aware, the loading time of a level, or also to go just "in-game" is ridiculously slow. It almost looks that the game needs an enormous amount of RAM or Mesa (or one of its components) is handling this part very badly.

Addition: My "loading time" issues are caused very likely because of too less video memory. The tested Radeon card has only 512MB but recommended seems to be 1GB of VRAM.

In my case I was able to launch the game with standard (or lower) performance profiles. AND, the first time it didn't run really smooth regardless of the "lights setting". Then I have started to experiment with some graphics values and also the additional installed software components. I came to the conclusion that the following two parts may interact counterproductive with recent Wine 7.x releases:

• Managed DirectX 9 which will be incorporated into .NET Framework 4.0

Both those are very old, while the first may interact negatively with Gallium Nine .NET Framework 4.0 is not really suited for Wine, Mono 7.x is the better option. Fortunately .NET Framework 4.0 will be not installed although it looks to be installed by the GOG.COM installer. So there exists a Wine hack to prevent the installation of the .NET Framework and enforces Mono. It looks that an equal hack preventing the installation of Managed DirectX 9 would be also quite useful.

It can help therefore to make a clone of the Wine prefix before installing it. This makes it possible to switch and exchange entire directories like system32 or syswow64. At the moment I have just removed the assembly directory in Windows and the DirectX for Managed Code in Microsoft.NET (in Windows).

A further side effect is that the KDE UI or X11 gets also slow in reaction when the game is exited. This can be resolved by a re-login of the user.

Long story short, if you wait patiently until the corresponding level is loaded, then this platformer game can make fun. (Although I prefer Super Mario 64, Banjo Kazooie or Crash Bandicoot.:wink: )

test@test-iMac:~$ inxi -b
System:    Host: test-iMac Kernel: 5.13.0-40-generic x86_64 bits: 64 Desktop: KDE Plasma 5.18.8 
           Distro: Ubuntu 20.04.4 LTS (Focal Fossa) 
Machine:   Type: Desktop System: Apple product: iMac12,2 v: 1.0 serial: <superuser/root required> 
           Mobo: Apple model: Mac-942B59F58194171B v: iMac12,2 serial: <superuser/root required> UEFI: Apple 
           v: IM121.88Z.0047.B1F.1201241648 date: 01/24/12 
CPU:       Quad Core: Intel Core i5-2500S type: MCP speed: 1596 MHz min/max: 1600/3700 MHz 
Graphics:  Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics driver: i915 v: kernel 
           Device-2: Advanced Micro Devices [AMD/ATI] Whistler [Radeon HD 6730M/6770M/7690M XT] driver: radeon v: kernel 
           Display: x11 server: X.Org 1.20.13 driver: modesetting,radeon FAILED: ati unloaded: fbdev,vesa 
           resolution: 2560x1440~60Hz 
           OpenGL: renderer: AMD TURKS (DRM 2.50.0 / 5.13.0-40-generic LLVM 14.0.0) 
           v: 3.3 Mesa 22.2.0-devel (git-6bef59f 2022-04-24 focal-oibaf-ppa) 
Network:   Device-1: Broadcom and subsidiaries NetXtreme BCM57765 Gigabit Ethernet PCIe driver: tg3 
           Device-2: Qualcomm Atheros AR93xx Wireless Network Adapter driver: ath9k 
Drives:    Local Storage: total: 961.01 GiB used: 158.97 GiB (16.5%) 
Info:      Processes: 218 Uptime: 4h 33m Memory: 7.74 GiB used: 2.22 GiB (28.6%) Shell: bash inxi: 3.0.38 

[okias]

@Francesco149 is there chance you can re-check, if it still hang for you? https://gitlab.freedesktop.org/mesa/mesa/-/issues/1408