10:38 AnonymouX47: Hello! Please, I need your help with AMD GPU reset.
10:38 AnonymouX47: I'm running Linux 7.1.8-arch1-3, Mesa 26.1.7-arch1.1, Radeon Graphics (radeonsi renoir ACO DRM 3.64 7.1.8-arch1-3).
10:38 AnonymouX47: I'm trying to test my branch of GNOME's Mutter (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5247) implementing GPU reset recovery on an AMD iGPU (Advanced Micro Devices [AMD/ATI] Renoir [Radeon Vega Mobile Series]). I've confirmed Mutter and applications running within it are using the iGPU.
10:39 AnonymouX47: I triggered resets using `sudo cat /sys/kernel/debug/dri/2/amdgpu_gpu_recover`. This only turned displays off briefly and back on, but did not affect GL contexts. The command printed `0` and dmesg reported successful MODE2 resets.
10:39 AnonymouX47: So, I tried a few things:
10:39 AnonymouX47: 1. Set `amdgpu.gpu_recovery=1`: Same result.
10:39 AnonymouX47: 2. Set `amdgpu.debug_mask=0x4`: Same result.
10:39 AnonymouX47: 3. Set `amdgpu.reset_method=2` (MODE1): Resets failed with code `-110`. The PC was unresponsive afterwards, had to force-shutdown.
10:39 AnonymouX47: 4. Set `amdgpu.reset_method=1` (MODE0): The kernel reports the mode as unsupported and falls back to AUTO -> MODE2, yielding the same result as earlier.
10:39 AnonymouX47: FWIW, I used this same method without any kernel module parameter modifications (maybe only `gpu_recovery=1`, I don't fully recall) a few months back on a previous installation of a different distro and it worked as expected i.e GL contexts were lost.
10:40 AnonymouX47: Please, what might be going on, and how can I trigger a reset that results in GL context loss?
10:40 AnonymouX47: If the dmesg logs would help, I can try to reproduce them.
10:40 AnonymouX47: I would really appreciate any help on this.
10:40 AnonymouX47: Thank you very much!
12:04 jadahl: if anyone have any suggestion how to trigger gpu reset of the egl context as per asked above, for testing purposes on amd hw, i'll forward anything to AnonymouX47 (he's having problem with IRC)
12:10 daniels: jadahl: just insert an idiotic shader like https://gitlab.collabora.com/daniels/texture-atlas-test/-/blob/master/obnoxious-fbo-load.c#L92
12:17 jadahl: in that case just testing with llvmpipe's reset logic is probably saner
12:29 MrCooper: pixelcluster: re https://pixelcluster.dev/VRAM-Overcommit/#fn:4 (footnote 4), only APUs can scan out from system RAM, not dGPUs
14:23 agd5f: pixelcluster, APUs can to scatter gather displays on both system memory and carve out and newer dGPUs can do scatter gather display on VRAM. However, currently we use a direct access aperture for VRAM in vmid 0 space to avoid the overhead of page tables. If we were to use page tables for VRAM in vmid 0, you could in theory do scatter gather display in VRAM.
15:24 mripard: rodrigovivi: it might not be for RAS, but it absolutely is for DRM. Anyone trying to introduce a new userspace API to DRM without anything more than a dumping tool would certainly not be merged.
15:25 mripard: rodrigovivi: now, I know that this discussion happens late and kind of after the facts, but we must document why this is ok for RAS and not for... everything else