[Linux/RADV, RX 7600] 3-5 fps in Kokiri Forest: vkQueueSubmit ~250-295 ms per frame while GPU time is ~11 ms; textures garbled at random

Naneek-code commented

2026-11-07 20:17:00 +00:00

(Migrated from github.com)

Hookshot version

Linux AppImage from the Linux AppImage workflow, main @ 170ce53c (Hookshot-foliage-linux-updater). Same results on main @ 4c8ff1e0 (with a local stub for hos_renderer_wait, before 60760695).

What kind of problem

Low fps or stutter (plus garbled graphics and, with larger mirror budgets, device lost)

What happened

The opening cutscenes run at a locked 60 fps. Right after the first cutscene, when the game goes to the Great Deku Tree / Kokiri Forest area, it drops to 3-5 fps.

The log shows the time is not spent on the GPU but inside vkQueueSubmit:

vk: a frame's replay time (ms): submit 91.24, ... queue submit 293.93, slot wait 0.13
vk: GPU time 11.1 ms a frame (the longest submission 4.1 ms)
vk: guest memory imported in place (alignment 4096)

In-scene numbers per run (last log windows before closing):

Run	Resizable BAR	`RX_VK_MIRROR_MB`	Mirrors in use	queue submit / frame	GPU time / frame	Picture
1	off (256 MB BAR heap)	default	928 MB	~250 ms	~10.5 ms	garbled
2	off	192	192 MB	(not logged)		correct
3	on (8 GB BAR)	192	192 MB	~243 ms	~8 ms	garbled
4 (`170ce53c`)	on	192	192 MB	~290-295 ms	~11-13 ms	garbled

So: Resizable BAR on/off and the mirror budget do not change the submit time. My guess (not verified): the guest memory is imported with VK_EXT_external_memory_host, which on amdgpu means userptr BOs, and the kernel re-validates them on every submit after the CPU writes to guest memory. That would explain a CPU-side submit cost that does not depend on GPU load.

Garbled textures: the whole 3D scene becomes coloured noise (the shapes of the ground and sky are still visible). Runs 2 and 3 had the same settings and gave opposite results, so it looks random / timing-dependent rather than tied to a setting.

Device lost with larger mirror budgets: with the default budget (mirrors reached 1648 MB) and with RX_VK_MIRROR_MB=1024, the GPU hangs every time when entering the Deku Tree area, right after pool ... took in 2 pools, the same pattern as #150. RADV reports a GPUVM permission fault and the kernel resets the GPU (the second time a MODE1 reset with VRAM lost):

vk: pool 0x116b000000..0x1172000000 took in 2 pools
vk: slow descriptor 2.9 ms: storage buffer (written) 0x116e50b000 size 0xf33080
vk: slow dispatch 2.9 ms: program 102f5b0abb0f1e63 (picked at 0.0), pipeline at 0.0, descriptors at 2.9
nvn: GPU waits in 5 s: 1 sync waits (5529 ms), 0 polls timed out (0 ms), 0 queue finishes (0 ms)
vk: slow upload 5461.3 ms: #457 0x1134917000 512x512x1 x1 levels 1 NVN 0x29, 2048 of 2048 KB
vk: slow dispatch 5462.0 ms: program 35de103a233e6361 (picked at 0.0), pipeline at 0.0, descriptors at 5462.0
radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent.
radv: GPUVM fault detected at address 0x8002c794b000.
GCVM_L2_PROTECTION_FAULT_STATUS: 0x501031
	 CLIENT_ID: (TCP) 0x8
	 PERMISSION_FAULTS: 3
vk: submit 85234 failed (-4)

With RX_VK_MIRROR_MB=192 there is no hang, but it runs at 3-5 fps as above.

The networks are left out on this card as expected (a network left out on this card, TAAU fd029a317a9a4b94 stood in for), and matrix multiplies in software (the cooperative matrices lack 16x8x16 f16) is logged.

Where in the game

Right after the first opening cutscene, entering the Great Deku Tree / Kokiri Forest area. Opening cutscenes are fine (60 fps).

How often

Every time (low fps); garbled textures sometimes; device lost every time with mirror budget >= 1 GB.

Graphics card and driver version

AMD Radeon RX 7600 8 GB (RADV NAVI33), Mesa 25.3.6, Vulkan 1.4.328, Resizable BAR tested off and on

CPU, RAM and operating system

Ryzen 5 5600X, 40 GB RAM, KDE neon (Ubuntu 24.04 base), kernel 7.0.0-42, KDE Plasma Wayland session. Game files on an NTFS HDD (ntfs3).

Changes from the defaults

hookshot_env.txt: RX_VK_MIRROR_MB=192 (runs 2-4), RX_VK_MIRROR_MB=1024 (hang test). No Insert-menu changes.

Other software hooked into the game

None

I can test any build or flag you suggest. I can't attach the full logs here, but I can paste any section you need.

### Hookshot version Linux AppImage from the `Linux AppImage` workflow, main @ `170ce53c` (Hookshot-foliage-linux-updater). Same results on main @ `4c8ff1e0` (with a local stub for `hos_renderer_wait`, before 60760695). ### What kind of problem Low fps or stutter (plus garbled graphics and, with larger mirror budgets, device lost) ### What happened The opening cutscenes run at a locked 60 fps. Right after the first cutscene, when the game goes to the Great Deku Tree / Kokiri Forest area, it drops to **3-5 fps**. The log shows the time is not spent on the GPU but inside `vkQueueSubmit`: ``` vk: a frame's replay time (ms): submit 91.24, ... queue submit 293.93, slot wait 0.13 vk: GPU time 11.1 ms a frame (the longest submission 4.1 ms) vk: guest memory imported in place (alignment 4096) ``` In-scene numbers per run (last log windows before closing): | Run | Resizable BAR | `RX_VK_MIRROR_MB` | Mirrors in use | queue submit / frame | GPU time / frame | Picture | |---|---|---|---|---|---|---| | 1 | off (256 MB BAR heap) | default | 928 MB | ~250 ms | ~10.5 ms | garbled | | 2 | off | 192 | 192 MB | (not logged) | | **correct** | | 3 | on (8 GB BAR) | 192 | 192 MB | ~243 ms | ~8 ms | garbled | | 4 (`170ce53c`) | on | 192 | 192 MB | ~290-295 ms | ~11-13 ms | garbled | So: Resizable BAR on/off and the mirror budget do not change the submit time. My guess (not verified): the guest memory is imported with `VK_EXT_external_memory_host`, which on amdgpu means userptr BOs, and the kernel re-validates them on every submit after the CPU writes to guest memory. That would explain a CPU-side submit cost that does not depend on GPU load. **Garbled textures:** the whole 3D scene becomes coloured noise (the shapes of the ground and sky are still visible). Runs 2 and 3 had the same settings and gave opposite results, so it looks random / timing-dependent rather than tied to a setting. **Device lost with larger mirror budgets:** with the default budget (mirrors reached 1648 MB) and with `RX_VK_MIRROR_MB=1024`, the GPU hangs every time when entering the Deku Tree area, right after `pool ... took in 2 pools`, the same pattern as #150. RADV reports a GPUVM permission fault and the kernel resets the GPU (the second time a MODE1 reset with VRAM lost): ``` vk: pool 0x116b000000..0x1172000000 took in 2 pools vk: slow descriptor 2.9 ms: storage buffer (written) 0x116e50b000 size 0xf33080 vk: slow dispatch 2.9 ms: program 102f5b0abb0f1e63 (picked at 0.0), pipeline at 0.0, descriptors at 2.9 nvn: GPU waits in 5 s: 1 sync waits (5529 ms), 0 polls timed out (0 ms), 0 queue finishes (0 ms) vk: slow upload 5461.3 ms: #457 0x1134917000 512x512x1 x1 levels 1 NVN 0x29, 2048 of 2048 KB vk: slow dispatch 5462.0 ms: program 35de103a233e6361 (picked at 0.0), pipeline at 0.0, descriptors at 5462.0 radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent. radv: GPUVM fault detected at address 0x8002c794b000. GCVM_L2_PROTECTION_FAULT_STATUS: 0x501031 CLIENT_ID: (TCP) 0x8 PERMISSION_FAULTS: 3 vk: submit 85234 failed (-4) ``` With `RX_VK_MIRROR_MB=192` there is no hang, but it runs at 3-5 fps as above. The networks are left out on this card as expected (`a network left out on this card`, TAAU `fd029a317a9a4b94` stood in for), and `matrix multiplies in software (the cooperative matrices lack 16x8x16 f16)` is logged. ### Where in the game Right after the first opening cutscene, entering the Great Deku Tree / Kokiri Forest area. Opening cutscenes are fine (60 fps). ### How often Every time (low fps); garbled textures sometimes; device lost every time with mirror budget >= 1 GB. ### Graphics card and driver version AMD Radeon RX 7600 8 GB (RADV NAVI33), Mesa 25.3.6, Vulkan 1.4.328, Resizable BAR tested off and on ### CPU, RAM and operating system Ryzen 5 5600X, 40 GB RAM, KDE neon (Ubuntu 24.04 base), kernel 7.0.0-42, KDE Plasma Wayland session. Game files on an NTFS HDD (ntfs3). ### Changes from the defaults `hookshot_env.txt`: `RX_VK_MIRROR_MB=192` (runs 2-4), `RX_VK_MIRROR_MB=1024` (hang test). No Insert-menu changes. ### Other software hooked into the game None I can test any build or flag you suggest. I can't attach the full logs here, but I can paste any section you need.

NotRexed commented

2026-11-07 20:24:39 +00:00

(Migrated from github.com)

Great report, thank you. 250-295 ms in vkQueueSubmit with ~11 ms of GPU time points at the submission itself on RADV (likely the imported host memory being re-validated per submit), not the GPU. I'll look into it; if you can, try RX_VK_IMPORT_CHUNK_MB=64 in hookshot_env.txt and say whether the submit time changes.

Great report, thank you. 250-295 ms in `vkQueueSubmit` with ~11 ms of GPU time points at the submission itself on RADV (likely the imported host memory being re-validated per submit), not the GPU. I'll look into it; if you can, try `RX_VK_IMPORT_CHUNK_MB=64` in `hookshot_env.txt` and say whether the submit time changes.

Naneek-code commented

2026-11-07 20:31:56 +00:00

(Migrated from github.com)

Two more data points from the same session (build 170ce53c, RX_VK_MIRROR_MB=192, Resizable BAR on), after walking around Kokiri Forest for a while:

1. The frame is serialized on the Presentation thread, the machine is mostly idle. top -H on the hookshot process:

Presentation thread   ~64% of one core
mkw_vk                ~27%
everything else        ~0%

System-wide: CPU ~28%, GPU ~6% busy. So the ~250-295 ms queue submit per frame looks like time blocked in the driver/kernel on that one thread, not CPU or GPU throughput.

2. VRAM fills up over time and the frame rate gets worse (3-5 fps -> 1.4 fps). At scene entry the log showed ~1.5 GB used; later:

vk: VRAM: 6875 MB used of 7278 MB allowed (471 MB of it free in the blocks); textures 4144 MB (budget 5232 MB), 2124 textures
vk: memory heaps: heap 0 (system): 10 blocks 584 MB, 37 allocations 526 MB; used 3304 of 19951 MB; heap 1 (device): 58 blocks 6668 MB, 2182 allocations 6196 MB; used 6875 of 7278 MB;
vk: memory: working set 7936 MB (peak 7939), private 7623 MB, staging 256 MB in 4 arenas
vk: 17040 presents, 1.4 fps; a frame: 2448 draws (0 skipped), 167 dispatches, 160 passes, 181 barriers, 6 submits, ...

The kernel agrees (/proc/<pid>/fdinfo): drm-resident-vram: 7190112 KiB, drm-resident-gtt: 3876968 KiB, and card-wide mem_info_vram_used 7754 of 8176 MB. With VRAM this full, amdgpu has to evict to GTT, which probably makes the submits slower still. But the ~250 ms submits were already there at ~1.5 GB VRAM, so this makes it worse rather than causing it.

Two more data points from the same session (build `170ce53c`, `RX_VK_MIRROR_MB=192`, Resizable BAR on), after walking around Kokiri Forest for a while: **1. The frame is serialized on the Presentation thread, the machine is mostly idle.** `top -H` on the hookshot process: ``` Presentation thread ~64% of one core mkw_vk ~27% everything else ~0% ``` System-wide: CPU ~28%, GPU ~6% busy. So the ~250-295 ms `queue submit` per frame looks like time blocked in the driver/kernel on that one thread, not CPU or GPU throughput. **2. VRAM fills up over time and the frame rate gets worse (3-5 fps -> 1.4 fps).** At scene entry the log showed ~1.5 GB used; later: ``` vk: VRAM: 6875 MB used of 7278 MB allowed (471 MB of it free in the blocks); textures 4144 MB (budget 5232 MB), 2124 textures vk: memory heaps: heap 0 (system): 10 blocks 584 MB, 37 allocations 526 MB; used 3304 of 19951 MB; heap 1 (device): 58 blocks 6668 MB, 2182 allocations 6196 MB; used 6875 of 7278 MB; vk: memory: working set 7936 MB (peak 7939), private 7623 MB, staging 256 MB in 4 arenas vk: 17040 presents, 1.4 fps; a frame: 2448 draws (0 skipped), 167 dispatches, 160 passes, 181 barriers, 6 submits, ... ``` The kernel agrees (`/proc/<pid>/fdinfo`): `drm-resident-vram: 7190112 KiB`, `drm-resident-gtt: 3876968 KiB`, and card-wide `mem_info_vram_used` 7754 of 8176 MB. With VRAM this full, amdgpu has to evict to GTT, which probably makes the submits slower still. But the ~250 ms submits were already there at ~1.5 GB VRAM, so this makes it worse rather than causing it.

alvaroum02-rgb commented

2026-11-07 20:42:59 +00:00

(Migrated from github.com)

El rendimiento no es bueno en mi rx 6700 xt, ryzen 5 5600 24 gb ram, 8 fps como maximo en el bosque kokiri, linux cachy os hyperland (Wayland) puedo compartir mi hookshok_log

hookshot_log.txt

El rendimiento no es bueno en mi rx 6700 xt, ryzen 5 5600 24 gb ram, 8 fps como maximo en el bosque kokiri, linux cachy os hyperland (Wayland) puedo compartir mi hookshok_log [hookshot_log.txt](https://github.com/user-attachments/files/34528444/hookshot_log.txt)

Naneek-code commented

2026-11-07 20:44:31 +00:00

(Migrated from github.com)

Tested RX_VK_IMPORT_CHUNK_MB at 4, 16 (default) and 64, everything else the same (170ce53c, RX_VK_MIRROR_MB=192, Resizable BAR on), in Kokiri Forest / Link's house:

`RX_VK_IMPORT_CHUNK_MB`	Imports	`slow present` queue submit (avg of last 12)	Frame `queue submit` (in scene)	GPU time / frame	fps
4	126 (241 ms in all)	~30 ms	~370-390 ms	~13.5 ms	~2.5
16 (default)	55 (162 ms in all)	~27 ms	~156-243 ms	~6-8 ms	~3.8
64	30 (400 ms in all)	~46 ms	~400 ms	~10 ms	~2.5

So changing the chunk size does not fix it. 64 is clearly worse per present (fewer but larger imports, 46 vs 27 ms), and 4 is not better than 16. The default looks best, but the runs were not in exactly the same spot (the 16 MB run was outside in the forest, the others in Link's house), so treat small differences as noise. In every case the frame is still ~25-40x the GPU time.

Separate finding, the garbled 3D from my first post: it is the Insert menu's Resolution option, not random. With Resolution: Auto the whole 3D scene is coloured noise (HUD and menu fine). With a fixed 50% it renders correctly, and switching between the two in the same session flips it right away. That matches the "Resolution Auto black screen" AMD note in the less-stutter release, so on RADV / RX 7600 Auto still breaks the picture, just as noise instead of black. I'll add screenshots of both in a follow-up comment.

Tested `RX_VK_IMPORT_CHUNK_MB` at 4, 16 (default) and 64, everything else the same (`170ce53c`, `RX_VK_MIRROR_MB=192`, Resizable BAR on), in Kokiri Forest / Link's house: | `RX_VK_IMPORT_CHUNK_MB` | Imports | `slow present` queue submit (avg of last 12) | Frame `queue submit` (in scene) | GPU time / frame | fps | |---|---|---|---|---|---| | 4 | 126 (241 ms in all) | ~30 ms | ~370-390 ms | ~13.5 ms | ~2.5 | | 16 (default) | 55 (162 ms in all) | ~27 ms | ~156-243 ms | ~6-8 ms | ~3.8 | | 64 | 30 (400 ms in all) | ~46 ms | ~400 ms | ~10 ms | ~2.5 | So changing the chunk size does not fix it. 64 is clearly worse per present (fewer but larger imports, 46 vs 27 ms), and 4 is not better than 16. The default looks best, but the runs were not in exactly the same spot (the 16 MB run was outside in the forest, the others in Link's house), so treat small differences as noise. In every case the frame is still ~25-40x the GPU time. **Separate finding, the garbled 3D from my first post:** it is the Insert menu's **Resolution** option, not random. With `Resolution: Auto` the whole 3D scene is coloured noise (HUD and menu fine). With a fixed `50%` it renders correctly, and switching between the two in the same session flips it right away. That matches the "Resolution Auto black screen" AMD note in the `less-stutter` release, so on RADV / RX 7600 Auto still breaks the picture, just as noise instead of black. I'll add screenshots of both in a follow-up comment.

Naneek-code commented

2026-11-07 20:47:01 +00:00

(Migrated from github.com)

ricardoluevano commented

2026-11-07 21:14:07 +00:00

(Migrated from github.com)

I had the same problems than naneek-code, had steamos in my legión go amd z1 extreme 16gb ram. And the CPU goes up to. Gpu low in my opinion. Using the same setup but in windows. It freeze before the intro and blackscreen loading screen

I had the same problems than naneek-code, had steamos in my legión go amd z1 extreme 16gb ram. And the CPU goes up to. Gpu low in my opinion. Using the same setup but in windows. It freeze before the intro and blackscreen loading screen <img width="4000" height="2252" alt="Image" src="https://github.com/user-attachments/assets/c0a60278-b05d-4feb-a77e-e0524e5a3617" />

Naneek-code commented

2026-11-07 21:42:30 +00:00

(Migrated from github.com)

Tested 40c3f851 (the THP change). No difference on this machine: in-scene queue submit is still ~285-640 ms per frame, ~2 fps, GPU time ~10-16 ms.

THP was never involved here, so this is a second cause on top of the one 40c3f851 fixes:

/sys/kernel/mm/transparent_hugepage/enabled is always [madvise] never (Ubuntu / KDE neon default)
the running hookshot process has AnonHugePages: 0 kB in /proc/<pid>/smaps_rollup

That probably fixes it for distros that default to always (CachyOS, Arch), like the RX 6700 XT report above, but not for madvise systems.

I also counted memory syscalls with strace -c -f -e trace=madvise,mprotect,munmap,mmap attached for 15 s while standing in Link's house:

% time     seconds  usecs/call     calls    errors syscall
 51,59    0,029796          15      1980           munmap
 43,89    0,025348          12      1980           mmap
  4,52    0,002608          27        95           mprotect

So no madvise at all (the VirtualFree decommit path is not being hit), but ~132 mmap + ~132 munmap per second, about 66 pairs per frame at ~2 fps. I don't know whether those touch the imported guest ranges or are driver-side BO maps, but if a munmap overlaps a userptr import it would trigger the same re-pin. Happy to run strace with arguments (-e trace=mmap,munmap for a few seconds, to see sizes and addresses) if that helps.

VRAM still fills quickly on this build (VRAM: 7198 MB used of 7552 MB allowed, textures 3338 MB) with RX_VK_MIRROR_MB=192.

Tested `40c3f851` (the THP change). No difference on this machine: in-scene `queue submit` is still ~285-640 ms per frame, ~2 fps, GPU time ~10-16 ms. THP was never involved here, so this is a second cause on top of the one 40c3f851 fixes: - `/sys/kernel/mm/transparent_hugepage/enabled` is `always [madvise] never` (Ubuntu / KDE neon default) - the running hookshot process has `AnonHugePages: 0 kB` in `/proc/<pid>/smaps_rollup` That probably fixes it for distros that default to `always` (CachyOS, Arch), like the RX 6700 XT report above, but not for `madvise` systems. I also counted memory syscalls with `strace -c -f -e trace=madvise,mprotect,munmap,mmap` attached for 15 s while standing in Link's house: ``` % time seconds usecs/call calls errors syscall 51,59 0,029796 15 1980 munmap 43,89 0,025348 12 1980 mmap 4,52 0,002608 27 95 mprotect ``` So no `madvise` at all (the `VirtualFree` decommit path is not being hit), but ~132 `mmap` + ~132 `munmap` per second, about 66 pairs per frame at ~2 fps. I don't know whether those touch the imported guest ranges or are driver-side BO maps, but if a `munmap` overlaps a userptr import it would trigger the same re-pin. Happy to run `strace` with arguments (`-e trace=mmap,munmap` for a few seconds, to see sizes and addresses) if that helps. VRAM still fills quickly on this build (`VRAM: 7198 MB used of 7552 MB allowed`, textures 3338 MB) with `RX_VK_MIRROR_MB=192`.

NotRexed commented

2026-11-07 22:19:55 +00:00

(Migrated from github.com)

Thanks for testing 40c3f851 and for the strace counts; that points to a second cause on madvise systems. Yes, a few seconds of strace -e trace=mmap,munmap with sizes and addresses would help.

Thanks for testing 40c3f851 and for the strace counts; that points to a second cause on `madvise` systems. Yes, a few seconds of `strace -e trace=mmap,munmap` with sizes and addresses would help.

Naneek-code commented

2026-11-08 00:21:21 +00:00

(Migrated from github.com)

Here's the strace -f -tt -e trace=mmap,munmap capture, 5 s in Link's house (40c3f851, ~2-3 fps), compared against /proc/<pid>/maps taken while the game was still running.

None of them touch the guest window. Every call is a CPU mapping of a DRM buffer object on the render node:

fd 9 -> /dev/dri/renderD128

 690  mmap(NULL, 81920, PROT_READ|PROT_WRITE, MAP_SHARED, 9, <bo offset>)
   2  mmap(NULL, 163840, PROT_READ|PROT_WRITE, MAP_SHARED, 9, <bo offset>)
 692  munmap(<addr>, 81920)

17326 21:18:37.549986 mmap(NULL, 81920, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0x1014a7000) = 0x79b9ca68e000
17326 21:18:37.550407 mmap(NULL, 81920, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0x112c28000) = 0x79b9bff9c000
17326 21:18:37.550587 munmap(0x79b9c448f000, 81920) = 0

Guest window in /proc/<pid>/maps: 0x100000000000-0x108000000000 rw-p (anonymous, 512 GB reserved).
All 692 munmap addresses are in 0x79b9b7530000 .. 0x79b9ca68e000, next to libLLVM and the other driver mappings. 0 of 692 overlap the guest window, so they can't invalidate the userptr imports.
Threads: 1083 of the 1384 calls are on the Presentation thread, 192 on sead::MainThread. That's ~140 map+unmap pairs per second, all 80 KB BOs, so it looks like a small buffer being created/mapped and destroyed per submit or per draw batch. It's cheap in itself (strace -c showed ~0.03 s of syscall time in 15 s), but it's churn on the same thread that sits in vkQueueSubmit.

So whatever re-pins the imports on madvise systems, it isn't madvise, munmap or THP. The remaining candidates for the userptr invalidation I can think of are the 95 mprotect calls in 15 s (if any of them land in the guest window) or page migration/compaction. I can strace mprotect with addresses the same way if useful.

One more checks:

Same PC on Windows 11 (RX 7600, Adrenalin, same HDD, same release foliage-linux-updater, no hookshot_env.txt):

	Linux / RADV (Mesa 25.3.6)	Windows 11 / Adrenalin
in-scene `queue submit` per frame	250-640 ms	0.6-0.75 ms
GPU time per frame	~10-16 ms	~12-16 ms
fps (`vi: frames presented`, game frames)	2-4	~37-45 (frame gen 2x on top)
`host memory import` / `guest memory imported in place`	yes	yes
mirrors	192 MB (larger ones hang the GPU here)	1312 MB, no hang

Same GPU work, ~400-1000x difference in the submit itself, so this really is the RADV/amdgpu submission path on Linux.

Here's the `strace -f -tt -e trace=mmap,munmap` capture, 5 s in Link's house (`40c3f851`, ~2-3 fps), compared against `/proc/<pid>/maps` taken while the game was still running. **None of them touch the guest window.** Every call is a CPU mapping of a DRM buffer object on the render node: ``` fd 9 -> /dev/dri/renderD128 690 mmap(NULL, 81920, PROT_READ|PROT_WRITE, MAP_SHARED, 9, <bo offset>) 2 mmap(NULL, 163840, PROT_READ|PROT_WRITE, MAP_SHARED, 9, <bo offset>) 692 munmap(<addr>, 81920) ``` ``` 17326 21:18:37.549986 mmap(NULL, 81920, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0x1014a7000) = 0x79b9ca68e000 17326 21:18:37.550407 mmap(NULL, 81920, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0x112c28000) = 0x79b9bff9c000 17326 21:18:37.550587 munmap(0x79b9c448f000, 81920) = 0 ``` - Guest window in `/proc/<pid>/maps`: `0x100000000000-0x108000000000 rw-p` (anonymous, 512 GB reserved). - All 692 `munmap` addresses are in `0x79b9b7530000 .. 0x79b9ca68e000`, next to libLLVM and the other driver mappings. **0 of 692 overlap the guest window**, so they can't invalidate the userptr imports. - Threads: 1083 of the 1384 calls are on the Presentation thread, 192 on `sead::MainThread`. That's ~140 map+unmap pairs per second, all 80 KB BOs, so it looks like a small buffer being created/mapped and destroyed per submit or per draw batch. It's cheap in itself (strace -c showed ~0.03 s of syscall time in 15 s), but it's churn on the same thread that sits in `vkQueueSubmit`. So whatever re-pins the imports on `madvise` systems, it isn't `madvise`, `munmap` or THP. The remaining candidates for the userptr invalidation I can think of are the 95 `mprotect` calls in 15 s (if any of them land in the guest window) or page migration/compaction. I can strace `mprotect` with addresses the same way if useful. **One more checks:** 1. **Same PC on Windows 11** (RX 7600, Adrenalin, same HDD, same release `foliage-linux-updater`, no `hookshot_env.txt`): | | Linux / RADV (Mesa 25.3.6) | Windows 11 / Adrenalin | |---|---|---| | in-scene `queue submit` per frame | 250-640 ms | **0.6-0.75 ms** | | GPU time per frame | ~10-16 ms | ~12-16 ms | | fps (`vi: frames presented`, game frames) | 2-4 | ~37-45 (frame gen 2x on top) | | `host memory import` / `guest memory imported in place` | yes | yes | | mirrors | 192 MB (larger ones hang the GPU here) | 1312 MB, no hang | Same GPU work, ~400-1000x difference in the submit itself, so this really is the RADV/amdgpu submission path on Linux.

Naneek-code commented

2026-11-08 00:23:37 +00:00

(Migrated from github.com)

Full files for the comment above: strace capture, /proc//maps taken during it, and the Konsole run log.

strace-mmap-5s.txt
run8-konsole-log.txt
proc-pid-maps.txt

Full files for the comment above: strace capture, /proc/<pid>/maps taken during it, and the Konsole run log. [strace-mmap-5s.txt](https://github.com/user-attachments/files/34531239/strace-mmap-5s.txt) [run8-konsole-log.txt](https://github.com/user-attachments/files/34531237/run8-konsole-log.txt) [proc-pid-maps.txt](https://github.com/user-attachments/files/34531238/proc-pid-maps.txt)