Re: amdgpu system freeze

[TeusLollo <TeusLollo@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 4190 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53787#issuecomment-2567160184

Comment:
The Mesa Shader Cache is populated by, namely, shaders, which are an important, yet secondary, aspect of modern graphical processing. 
If shaders were to fail, someway, you'd probably get botched graphics somewhere, but most rendering engines would continue running. Even then, `DWL` should probably just crash and send you back to the console, not freeze in a non-responsive state. Linux kernel was still running, however, since it was responsive to REISUB. 

A file descriptor failure is when application utilizing a given file fails to properly terminate its access: https://pradeesh-kumar.medium.com/you-must-be-aware-of-file-descriptor-leaking-600cee607dd6
Indeed, shaders are put into that cache because they need to be pre-generated by rendering engines based on GPU capabilities/compatibility, and having them in caches allows skipping the generation phase once it has been done once. 
The fact that file is reported leaking may not be related to freezes, it may just be a bug in `DWL`. 

A couple of questions:

1) After manually deleting the contents of `~/.cache/`, did you actually reboot your entire system? Because some shaders can actually be loaded into memory on userspace start-up, thus they could have been still into memory even after their files were deleted (This is especially likely if `DWL` was already running). That would neatly explain why a new user instead gave no crashes, because in that case the system was forced to re-generate and re-load its shaders, something which would not happen if you just deleted the cache (Pre-loaded shaders will stay in memory, and only after a cache re-generation and a system/application reboot they will actually be cleared) 

2) The fact that you get not crashes while not in browser (Modern browsers rely on graphical acceleration) or videos (Most media players rely on graphical acceleration, and some even on hardware-based audio acceleration) hint at a problem with graphical acceleration itself. Is there a way to run `DWL` in a software-only (No graphical acceleration) mode? If there is one, and you can test successfully that no freezes happen, it may indeed be a bug in `DWL`

3) I can reproduce fairly reliably some hard WM freezes (Although not "black screen" kind of freezes) with `sway` when I run a WINE/PROTON setup and attempt to utilize some Windows-only applications built in .NET Framework. This may hint at some underlying problem with the AMDGPU driver. Indeed, on Windows, OpenGL support on AMD is said to be botched on several levels, so don't expect the AMDGPU driver to be perfect in all of its components, especially if `DWL` relies on some OpenGL compatibility features, or some more obscure functions which haven't been tested in years. If `DWL` developers do most of their tests on an architecture different than AMDGPU, it wouldn't be too surprising that some unforeseen behaviours manifest on AMDGPU-based setups.

4) Are you absolutely sure that `DWL` generates its own shaders and puts them into `~/.cache/`? (Indeed, does it make any use of shaders at all?). Because, if it does, it should have a built-in routine checking against installed `mesa` version and compatibility of cached shaders, and a forced re-generation process of those shaders if something in user setup changes (`Mesa` update, `DWL` update with modification on graphical acceleration backend, change of GPU device even). I would be surprised you were the first to get these problems if there are no safeguards in place.

5) Lastly, if you could try and use a different WM for some time (I know, it can take weeks to redo a satisfying setup on a different WM), and you can't replicate this, than it's pretty much guaranteed that `DWL` is having a problem. 

6) Remember that all applications ran from ~ will make use of the Mesa Shader cache, thus something else may be polluting that cache. `steam`-launched applications however should be using their own cache, unless something's changed in the meantime, or you did some funky symlinking in your config.