#2156 - [REGRESSION v2.1.0] Severe FPS drops in Kokiri Forest - worked fine on v2.0.14 (RTX 5050 8GB) - MagicBeanDev/Hookshot

guilhermervalle commented

2026-11-11 05:11:35 +00:00

(Migrated from github.com)

IMPORTANT: This is a regression from v2.0.14

On the previous version (v2.0.14), I played through Kokiri Forest
with similar settings and had NO performance issues — ran smoothly
at high FPS in the exact same area. The problem started only after
updating to v2.1.0.

This appears to be a REGRESSION in v2.1.0, not a hardware limitation
of 8GB GPUs. Something changed between v2.0.14 and v2.1.0 that
increased VRAM pressure or broke texture streaming.

Hookshot version

v2.1.0

What kind of problem

Graphics (missing, black or wrong-coloured things, lighting, flicker)

What happened

Inside the Great Deku Tree dungeon, the game runs smoothly at 120+ FPS with no issues. Upon exiting to Kokiri Forest, FPS drops drastically to 14-25 with severe stuttering. The problem persists even after walking around the area for several minutes (ruling out shader compilation).

Task Manager shows:

GPU VRAM dedicated: 7.4 / 8.0 GB (saturated)
GPU VRAM shared (system RAM spillover): 4.5 GB
GPU utilization: 85%

This is a REGRESSION — the same area (Kokiri Forest) ran smoothly at high FPS on v2.0.14 with the same 8GB GPU. Something changed in v2.1.0 that caused VRAM pressure to spike dramatically.

The VRAM saturation shown in Task Manager is a SYMPTOM, not the root cause — on v2.0.14 the same assets fit fine in 8GB VRAM.

On a second pass through the same area, the problem persists.

Where in the game

Kokiri Forest (outdoor village area), occurs after exiting Link's house or after completing/exiting the Great Deku Tree. Reproducible every time in the open forest area.

How often

Every time

Graphics card and driver version

NVIDIA GeForce RTX 5050 8GB, driver 616.56

CPU, RAM and operating system

Ryzen 5 8600G, 32GB RAM 5600mhz DDR5, Windows 11

Changes from the defaults

Game language (at build time): Portuguese (BR)
Profile: Handheld (was Docked - changed to reduce VRAM usage)
DLSS model: 2 L (was NVIDIA default)
Anisotropic filtering: 8x (was 16x)
Render resolution: Quality 67%
Frame generation: Off during testing
Game frame rate cap: 60
NVIDIA Reflex: On + Boost
Fullscreen: On

With these workarounds, minimum FPS improved from ~14 to ~43 in the same area, and VRAM shared dropped from 4.5 GB to 2.4 GB.

Possible v2.1.0 changes that may have introduced the regression:

Anisotropic filtering now defaulting to 16x (new in v2.1.0)
HKSTATE2 pipeline state list (introduced in rc.2)
Mesh shaders changes
Support for 5K output resolution may have changed buffer allocation
DLSS Transformer (K) as new default model

I could try bisecting between v2.0.14 and v2.1.0 release candidates (rc.1, rc.2, rc.3) to narrow down which version introduced the regression if that would be helpful.

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

hookshot_log.1.txt
hookshot_log.txt

Screenshots or video

Image 1: In-game footage during the issue - showing 42 FPS in Kokiri Forest. This is actually one of the better moments; in some parts of the forest and when first exiting Deku Tree, FPS drops as low as 13-14 FPS with heavy stuttering (see minimum range stated above: 14-25 FPS). VRAM 7.4/8.0 GB saturated, 4.5 GB spilling to system RAM.

Image 2: After applying workaround (Handheld profile + DLSS 2L + Anisotropic 8x) - same area, VRAM shared dropped to 2.4 GB, minimum FPS improved to 43+.

Before you send it

I'm on the newest release, or the problem is still there on it.
I searched the open issues for this problem.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

## IMPORTANT: This is a regression from v2.0.14 On the previous version (v2.0.14), I played through Kokiri Forest with similar settings and had NO performance issues — ran smoothly at high FPS in the exact same area. The problem started only after updating to v2.1.0. This appears to be a REGRESSION in v2.1.0, not a hardware limitation of 8GB GPUs. Something changed between v2.0.14 and v2.1.0 that increased VRAM pressure or broke texture streaming. ### Hookshot version v2.1.0 ### What kind of problem Graphics (missing, black or wrong-coloured things, lighting, flicker) ### What happened Inside the Great Deku Tree dungeon, the game runs smoothly at 120+ FPS with no issues. Upon exiting to Kokiri Forest, FPS drops drastically to 14-25 with severe stuttering. The problem persists even after walking around the area for several minutes (ruling out shader compilation). Task Manager shows: - GPU VRAM dedicated: 7.4 / 8.0 GB (saturated) - GPU VRAM shared (system RAM spillover): 4.5 GB - GPU utilization: 85% **This is a REGRESSION** — the same area (Kokiri Forest) ran smoothly at high FPS on v2.0.14 with the same 8GB GPU. Something changed in v2.1.0 that caused VRAM pressure to spike dramatically. The VRAM saturation shown in Task Manager is a SYMPTOM, not the root cause — on v2.0.14 the same assets fit fine in 8GB VRAM. On a second pass through the same area, the problem persists. ### Where in the game Kokiri Forest (outdoor village area), occurs after exiting Link's house or after completing/exiting the Great Deku Tree. Reproducible every time in the open forest area. ### How often Every time ### Graphics card and driver version NVIDIA GeForce RTX 5050 8GB, driver 616.56 ### CPU, RAM and operating system Ryzen 5 8600G, 32GB RAM 5600mhz DDR5, Windows 11 ### Changes from the defaults - Game language (at build time): Portuguese (BR) - Profile: Handheld (was Docked - changed to reduce VRAM usage) - DLSS model: 2 L (was NVIDIA default) - Anisotropic filtering: 8x (was 16x) - Render resolution: Quality 67% - Frame generation: Off during testing - Game frame rate cap: 60 - NVIDIA Reflex: On + Boost - Fullscreen: On With these workarounds, minimum FPS improved from ~14 to ~43 in the same area, and VRAM shared dropped from 4.5 GB to 2.4 GB. ### Possible v2.1.0 changes that may have introduced the regression: - Anisotropic filtering now defaulting to 16x (new in v2.1.0) - HKSTATE2 pipeline state list (introduced in rc.2) - Mesh shaders changes - Support for 5K output resolution may have changed buffer allocation - DLSS Transformer (K) as new default model I could try bisecting between v2.0.14 and v2.1.0 release candidates (rc.1, rc.2, rc.3) to narrow down which version introduced the regression if that would be helpful. ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot_log.1.txt](https://github.com/user-attachments/files/34671301/hookshot_log.1.txt) [hookshot_log.txt](https://github.com/user-attachments/files/34671300/hookshot_log.txt) ### Screenshots or video Image 1: In-game footage during the issue - showing 42 FPS in Kokiri Forest. This is actually one of the better moments; in some parts of the forest and when first exiting Deku Tree, FPS drops as low as 13-14 FPS with heavy stuttering (see minimum range stated above: 14-25 FPS). VRAM 7.4/8.0 GB saturated, 4.5 GB spilling to system RAM. <img width="1568" height="516" alt="image" src="https://github.com/user-attachments/assets/8579832b-1818-45dd-9c7d-3c5aca801170" /> Image 2: After applying workaround (Handheld profile + DLSS 2L + Anisotropic 8x) - same area, VRAM shared dropped to 2.4 GB, minimum FPS improved to 43+. <img width="1006" height="712" alt="image" src="https://github.com/user-attachments/assets/7800f705-276c-446e-817c-ba6a9a78a1ca" /> ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

quazardous commented

2026-11-11 09:25:53 +00:00

(Migrated from github.com)

Some numbers from a very different machine, in case they help triage: the same
"forest slow, dungeon fine" split shows up on an integrated AMD GPU, and the
game's own log says what the forest costs that the dungeon does not.

Setup: ROG Ally X — Ryzen Z1 Extreme, Radeon 780M (RDNA3), 24 GB shared, 8 GB
of it carved out for the GPU in the UEFI; Linux (Bazzite, kernel 7.2.15, RADV,
Mesa 26.2.6), Vulkan 1.4. 1280x720, quality preset Minimum, FSR, no frame
generation. Same save, same route every run, driven headlessly so the two
versions get the identical path: load, then the debug teleport to
InsideTheDekuTree, then 10 s walking forward.

The forest and the dungeon, in the same v2.1.0 run

Both lines are the game's own vk: counters, a few seconds apart:

	Kokiri Forest	Inside the Deku Tree
presented	15–32 fps	21–28 fps
draws a frame	1475	540
passes a frame	107	223
textures resident	1097 (3146 MB)	798 (2440 MB)
texture budget	2560 MB	2560 MB
GPU time a frame	16.5 ms	21.0 ms

The forest holds 3146 MB of textures against a 2560 MB budget, and the log
shows what the renderer then does about it:

vk: 60 new ASTC textures left for a later frame (this frame's uploads took their budget; 793 so far)
vk: 475 textures retired (549 left, 2342 MB)
vk: VRAM: 4908 MB used of 10678 MB allowed (1673 MB of it free in the blocks); textures 2239 MB (budget 2560 MB), 638 textures

Inside the Deku Tree the same counter moves by 1 to 6 textures a sample. So on
this machine the forest is both ~3x the draws and the only place that pushes
texture memory past its budget and makes the renderer evict and defer uploads —
which is the texture-streaming pressure you inferred from Task Manager, visible
in the game's own numbers rather than the OS's.

On the regression itself I have to be careful

Measuring the same route on v2.0.13 and on v2.1.0, the walk inside the Deku Tree
went from 21.9 ms a frame (45.7 fps) to 37.3 ms (26.8 fps), and the game's GPU
time from 14.4 ms to 21.0 ms for a frame of nearly identical content (531 -> 540
draws, 218 -> 223 passes, 2445 -> 2440 MB of textures). The first forest frame
after the save loads is bit-identical between the two versions, so nothing
about what is drawn changed — only what it costs.

But my distro updated Mesa between those two measurements (RADV
driver 0x6400001 -> 0x6400007), so that delta is not attributable to
Hookshot yet. I am rebuilding v2.0.13 to re-measure it on today's driver and
will post the result either way; please don't count the before/after above as
evidence until then.

If it helps the reporter produce comparable numbers

RX_VK_FRAME_LOG=<file> writes one line per frame (frame, time, frametime in
ms), and hookshot_log.txt already carries vi: N frames presented (X fps over the last 5.0 s), vk: GPU time X ms a frame, and the textures N (M MB) /
budget pair quoted above. Those three say whether a machine is GPU-bound or
evicting textures; Task Manager's VRAM figure cannot tell them apart.

Some numbers from a very different machine, in case they help triage: the same "forest slow, dungeon fine" split shows up on an integrated AMD GPU, and the game's own log says what the forest costs that the dungeon does not. **Setup:** ROG Ally X — Ryzen Z1 Extreme, Radeon 780M (RDNA3), 24 GB shared, 8 GB of it carved out for the GPU in the UEFI; Linux (Bazzite, kernel 7.2.15, RADV, Mesa 26.2.6), Vulkan 1.4. 1280x720, quality preset Minimum, FSR, no frame generation. Same save, same route every run, driven headlessly so the two versions get the identical path: load, then the debug teleport to `InsideTheDekuTree`, then 10 s walking forward. ### The forest and the dungeon, in the same v2.1.0 run Both lines are the game's own `vk:` counters, a few seconds apart: | | Kokiri Forest | Inside the Deku Tree | |---|---|---| | presented | 15–32 fps | 21–28 fps | | draws a frame | **1475** | 540 | | passes a frame | 107 | 223 | | textures resident | **1097 (3146 MB)** | 798 (2440 MB) | | texture budget | 2560 MB | 2560 MB | | GPU time a frame | 16.5 ms | 21.0 ms | The forest holds **3146 MB of textures against a 2560 MB budget**, and the log shows what the renderer then does about it: ``` vk: 60 new ASTC textures left for a later frame (this frame's uploads took their budget; 793 so far) vk: 475 textures retired (549 left, 2342 MB) vk: VRAM: 4908 MB used of 10678 MB allowed (1673 MB of it free in the blocks); textures 2239 MB (budget 2560 MB), 638 textures ``` Inside the Deku Tree the same counter moves by 1 to 6 textures a sample. So on this machine the forest is both ~3x the draws and the only place that pushes texture memory past its budget and makes the renderer evict and defer uploads — which is the texture-streaming pressure you inferred from Task Manager, visible in the game's own numbers rather than the OS's. ### On the regression itself I have to be careful Measuring the same route on v2.0.13 and on v2.1.0, the walk inside the Deku Tree went from 21.9 ms a frame (45.7 fps) to 37.3 ms (26.8 fps), and the game's GPU time from 14.4 ms to 21.0 ms for a frame of nearly identical content (531 -> 540 draws, 218 -> 223 passes, 2445 -> 2440 MB of textures). The first forest frame after the save loads is **bit-identical** between the two versions, so nothing about what is drawn changed — only what it costs. But my distro updated Mesa between those two measurements (RADV `driver 0x6400001` -> `0x6400007`), so that delta is not attributable to Hookshot yet. I am rebuilding v2.0.13 to re-measure it on today's driver and will post the result either way; please don't count the before/after above as evidence until then. ### If it helps the reporter produce comparable numbers `RX_VK_FRAME_LOG=<file>` writes one line per frame (frame, time, frametime in ms), and `hookshot_log.txt` already carries `vi: N frames presented (X fps over the last 5.0 s)`, `vk: GPU time X ms a frame`, and the `textures N (M MB)` / `budget` pair quoted above. Those three say whether a machine is GPU-bound or evicting textures; Task Manager's VRAM figure cannot tell them apart.

jabbaxipil commented

2026-11-11 15:41:23 +00:00

(Migrated from github.com)

A 12 GB data point to go with the Ally X numbers above: on a card with room, the same Kokiri scene fits its texture budget, and 2.1 is faster than 2.0.14 there, not slower.

RTX 4070 12 GB, Linux, NVIDIA 615.71.09, 2560x1440 output, DLAA, frame generation 3x, Quality preset at its default. 2.1.0-rc.3 nightly (46-gddafc1f). From the game's own vk: VRAM: lines:

Kokiri stream, standing still: 8.2-8.3 GB used, textures 4.1 GB of a 6144 MB texture budget.
Spinning the camera at the same spot: 8.6-8.8 GB used, textures 4.3-4.8 GB.
Highest texture use in a 17-minute session: 5.6 GB, still under the 6144 MB budget.

From v2.0.14 to v2.1.0-rc.3 on this card, Kokiri at 2,000-2,399 draws per frame went from 34-40 fps to about 54 fps (CPU-limited on both).

So at these settings Kokiri uses more VRAM than an 8 GB card has, which fits the shared-memory spill in your Task Manager numbers. I have no VRAM figures from v2.0.14 on this card, so I can't say whether 2.1 uses more than 2.0.14 did.

A 12 GB data point to go with the Ally X numbers above: on a card with room, the same Kokiri scene fits its texture budget, and 2.1 is faster than 2.0.14 there, not slower. RTX 4070 12 GB, Linux, NVIDIA 615.71.09, 2560x1440 output, DLAA, frame generation 3x, Quality preset at its default. 2.1.0-rc.3 nightly (46-gddafc1f). From the game's own `vk: VRAM:` lines: - Kokiri stream, standing still: 8.2-8.3 GB used, textures 4.1 GB of a 6144 MB texture budget. - Spinning the camera at the same spot: 8.6-8.8 GB used, textures 4.3-4.8 GB. - Highest texture use in a 17-minute session: 5.6 GB, still under the 6144 MB budget. From v2.0.14 to v2.1.0-rc.3 on this card, Kokiri at 2,000-2,399 draws per frame went from 34-40 fps to about 54 fps (CPU-limited on both). So at these settings Kokiri uses more VRAM than an 8 GB card has, which fits the shared-memory spill in your Task Manager numbers. I have no VRAM figures from v2.0.14 on this card, so I can't say whether 2.1 uses more than 2.0.14 did.

quazardous commented

2026-11-11 16:34:48 +00:00

(Migrated from github.com)

Following up on my comment above, where I measured v2.0.13 against v2.1.0 and
then said the difference was not attributable because my driver had changed
between the two. I have now held the driver fixed, and it is attributable.

First, a correction to that comment. I wrote "Mesa 26.2.6" and "my distro
updated Mesa between those two measurements". Both are wrong in the same way:
26.2.6 is the host system's Mesa, and the game here runs in a Fedora 41
container and loads that container's RADV. The driver versions I quoted from
the game's log were right — driver 0x6400001 and 0x6400007 — but they decode
as 25.0.1 and 25.0.7, not 26.2.x. So read the whole setup line as
RADV, Mesa 25.0.x, Fedora 41.

Now the test. I unpacked Mesa 25.0.1 beside the container and pointed the
game at it with VK_DRIVER_FILES, so the only thing that differs from this
morning's run is the driver. The game confirms it loaded:
driver 0x6400001. Same machine, same save, same route (teleport to the Deku
Tree, then 10 s walking forward), same settings:

	driver	frametime, walk	GPU time a frame
v2.0.13 (3 runs)	25.0.1	22.00 / 21.09 / 21.86 ms (~46 fps)	15.0 / 12.7 / 14.4 ms
v2.1.0	25.0.7	37.26 ms (26.8 fps)	21.0 ms
v2.1.0	25.0.1	37.49 ms (26.7 fps)	20.9 ms

v2.1.0 on the old driver and v2.1.0 on the new one differ by 0.6%. The driver
has nothing to do with it.

So on this hardware the Deku Tree walk costs ~70% more frame time in v2.1.0
than in v2.0.13 — 21.9 ms to 37.3 ms — and the extra is GPU-side: 14.4 ms to
21.0 ms for a frame of nearly identical content (531 -> 540 draws, 218 -> 223
passes, 2445 -> 2440 MB of textures), with the first forest frame after the save
loads being bit-identical between the two versions. Nothing about what is drawn
changed; what it costs did.

Numbers of runs, so you can weigh it: three runs of v2.0.13, one run of v2.1.0
per driver. The two v2.1.0 runs agree to within 0.6% of each other and the three
v2.0.13 runs within 4%, so I did not think more repeats would change the answer
— but say the word and I will run more.

This is a different machine and a different GPU vendor from the reporter's
RTX 5050, which makes it unlikely to be a vendor-specific driver problem on
their side either.

Following up on my comment above, where I measured v2.0.13 against v2.1.0 and then said the difference was not attributable because my driver had changed between the two. I have now held the driver fixed, and it is attributable. **First, a correction to that comment.** I wrote "Mesa 26.2.6" and "my distro updated Mesa between those two measurements". Both are wrong in the same way: 26.2.6 is the host system's Mesa, and the game here runs in a Fedora 41 container and loads *that* container's RADV. The driver versions I quoted from the game's log were right — `driver 0x6400001` and `0x6400007` — but they decode as **25.0.1** and **25.0.7**, not 26.2.x. So read the whole setup line as **RADV, Mesa 25.0.x, Fedora 41**. **Now the test.** I unpacked Mesa 25.0.1 beside the container and pointed the game at it with `VK_DRIVER_FILES`, so the only thing that differs from this morning's run is the driver. The game confirms it loaded: `driver 0x6400001`. Same machine, same save, same route (teleport to the Deku Tree, then 10 s walking forward), same settings: | | driver | frametime, walk | GPU time a frame | |---|---|---|---| | v2.0.13 (3 runs) | 25.0.1 | 22.00 / 21.09 / 21.86 ms (**~46 fps**) | 15.0 / 12.7 / 14.4 ms | | v2.1.0 | 25.0.7 | 37.26 ms (**26.8 fps**) | 21.0 ms | | v2.1.0 | **25.0.1** | 37.49 ms (**26.7 fps**) | 20.9 ms | v2.1.0 on the old driver and v2.1.0 on the new one differ by 0.6%. The driver has nothing to do with it. So on this hardware the Deku Tree walk costs **~70% more frame time in v2.1.0 than in v2.0.13** — 21.9 ms to 37.3 ms — and the extra is GPU-side: 14.4 ms to 21.0 ms for a frame of nearly identical content (531 -> 540 draws, 218 -> 223 passes, 2445 -> 2440 MB of textures), with the first forest frame after the save loads being bit-identical between the two versions. Nothing about what is drawn changed; what it costs did. Numbers of runs, so you can weigh it: three runs of v2.0.13, one run of v2.1.0 per driver. The two v2.1.0 runs agree to within 0.6% of each other and the three v2.0.13 runs within 4%, so I did not think more repeats would change the answer — but say the word and I will run more. This is a different machine and a different GPU vendor from the reporter's RTX 5050, which makes it unlikely to be a vendor-specific driver problem on their side either.

quazardous commented

2026-11-11 16:42:38 +00:00

(Migrated from github.com)

More runs, as offered — and they change how I should have justified the
comparison, though not its answer.

In my last comment I argued that two runs were enough because "the two v2.1.0
runs agree to within 0.6%". That was luck between two runs, not the real spread:
four more runs of the same build on the same driver land anywhere between 32.1
and 37.5 ms. Please disregard that sentence.

Here is everything, same scenario, same save, same route, frame time measured
over the 10 s walk and GPU time as the renderer reports it:

	n	frametime a frame	GPU time a frame
v2.0.13 / RADV 25.0.1	3	21.09, 21.86, 22.00 ms	12.7, 14.4, 15.0 ms
v2.1.0 / RADV 25.0.7	5	32.12, 32.31, 37.26, 37.35, 37.45 ms	19.5, 20.8, 21.0, 21.8, 22.2 ms
v2.1.0 / RADV 25.0.1	1	37.49 ms	20.9 ms

The two versions do not overlap on either measure: the slowest v2.0.13 frame
(22.00 ms) is still 10 ms faster than the fastest v2.1.0 one (32.12 ms), and the
worst v2.0.13 GPU time (15.0 ms) is below the best v2.1.0 one (19.5 ms). So the
conclusion stands and is now properly supported rather than asserted — v2.1.0
costs about 1.5x the frame time and 1.45x the GPU time of v2.0.13 in this
scene, on a driver that did not change.

The frame time is the noisier of the two (32-37 ms within one build) because it
carries the CPU side as well; the GPU time is the tighter number and the one the
regression shows up in most cleanly. If you want a specific comparison run on
this hardware — another scene, a particular setting, an rc build — it is about
two minutes a run now, so ask.

More runs, as offered — and they change how I should have justified the comparison, though not its answer. In my last comment I argued that two runs were enough because "the two v2.1.0 runs agree to within 0.6%". That was luck between two runs, not the real spread: four more runs of the same build on the same driver land anywhere between 32.1 and 37.5 ms. Please disregard that sentence. Here is everything, same scenario, same save, same route, frame time measured over the 10 s walk and GPU time as the renderer reports it: | | n | frametime a frame | GPU time a frame | |---|---|---|---| | v2.0.13 / RADV 25.0.1 | 3 | 21.09, 21.86, 22.00 ms | 12.7, 14.4, 15.0 ms | | v2.1.0 / RADV 25.0.7 | 5 | 32.12, 32.31, 37.26, 37.35, 37.45 ms | 19.5, 20.8, 21.0, 21.8, 22.2 ms | | v2.1.0 / RADV 25.0.1 | 1 | 37.49 ms | 20.9 ms | The two versions do not overlap on either measure: the slowest v2.0.13 frame (22.00 ms) is still 10 ms faster than the fastest v2.1.0 one (32.12 ms), and the worst v2.0.13 GPU time (15.0 ms) is below the best v2.1.0 one (19.5 ms). So the conclusion stands and is now properly supported rather than asserted — v2.1.0 costs about **1.5x the frame time and 1.45x the GPU time** of v2.0.13 in this scene, on a driver that did not change. The frame time is the noisier of the two (32-37 ms within one build) because it carries the CPU side as well; the GPU time is the tighter number and the one the regression shows up in most cleanly. If you want a specific comparison run on this hardware — another scene, a particular setting, an rc build — it is about two minutes a run now, so ask.

NotRexed commented

2026-11-11 21:25:36 +00:00

(Migrated from github.com)

Thanks for the report. Reports of the same problem are now collected in #995, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #995 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened.

jabbaxipil commented

2026-11-12 02:27:45 +00:00

(Migrated from github.com)

A desktop RDNA3 data point on v2.1.0, to set beside quazardous' 780M numbers above. I have no v2.0.13 run on this machine, so this shows what v2.1.0 costs here, not a before/after.

Setup: RX 7900 XTX 24 GB, RADV (Mesa 26.2.6), Ryzen 7 5800X3D, 32 GB, Ubuntu 24.04, X11. v2.1.0 (source e561602e). Stock settings except fullscreen, output 2560x1440 and render resolution 100%: game's own upscaler, frame generation off, 60 cap, no RX_VK_ variables (so no parallel replay, VRAM compaction off). udmabuf access on (guest memory as dma-bufs: yes).

	Kokiri Forest, stream view, standing	Inside the Deku Tree, ~25 s walk
windows	24	10
fps	36.2	45.4 (36.5-51.0)
draws / passes a frame	2,726 / 174	811 / 228
GPU time a frame	16.8 ms	11.0 ms
replay submit a frame	20.7 ms	7.4 ms
memory sync	5.3 ms	1.1 ms

Across the whole session, GPU time was 16-19.5 ms a frame at 2,000-4,600 draws, and fps stayed at 29-37 in that range.
At the Kokiri view the card reported 67-76% busy, but at only about 100-115 W average (session maximum 204 W) and 60 C junction. So it is occupied for most of the frame without being loaded.
For contrast, on the same CPU model with an RTX 4070 on Linux, v2.1.0-rc.3 (v2.1.0 plus the update-track change) ran Kokiri at 2,000-2,599 draws at 52-55 fps with frame generation off and RX_VK_PARALLEL=4. On a later nightly, with DLAA and frame generation on, GPU time there was 3.6-4.3 ms a frame at 1,970-2,780 draws.

My reading, not proven: the Deku Tree pass count matches quazardous' route (228 vs 223). A 7900 XTX at 2560x1440 needs 11.0 ms of GPU time there, close to what the 780M at 720p needed on v2.0.13 (12.7-15.0 ms). That looks more like a fixed per-frame GPU cost on RADV than shading load that scales with the card.

Log available on request.

A desktop RDNA3 data point on v2.1.0, to set beside quazardous' 780M numbers above. I have no v2.0.13 run on this machine, so this shows what v2.1.0 costs here, not a before/after. **Setup:** RX 7900 XTX 24 GB, RADV (Mesa 26.2.6), Ryzen 7 5800X3D, 32 GB, Ubuntu 24.04, X11. v2.1.0 (source e561602e). Stock settings except fullscreen, output 2560x1440 and render resolution 100%: game's own upscaler, frame generation off, 60 cap, no `RX_VK_` variables (so no parallel replay, VRAM compaction off). udmabuf access on (`guest memory as dma-bufs: yes`). | | Kokiri Forest, stream view, standing | Inside the Deku Tree, ~25 s walk | |---|---|---| | windows | 24 | 10 | | fps | 36.2 | 45.4 (36.5-51.0) | | draws / passes a frame | 2,726 / 174 | 811 / 228 | | GPU time a frame | 16.8 ms | 11.0 ms | | replay submit a frame | 20.7 ms | 7.4 ms | | memory sync | 5.3 ms | 1.1 ms | - Across the whole session, GPU time was 16-19.5 ms a frame at 2,000-4,600 draws, and fps stayed at 29-37 in that range. - At the Kokiri view the card reported 67-76% busy, but at only about 100-115 W average (session maximum 204 W) and 60 C junction. So it is occupied for most of the frame without being loaded. - For contrast, on the same CPU model with an RTX 4070 on Linux, v2.1.0-rc.3 (v2.1.0 plus the update-track change) ran Kokiri at 2,000-2,599 draws at 52-55 fps with frame generation off and `RX_VK_PARALLEL=4`. On a later nightly, with DLAA and frame generation on, GPU time there was 3.6-4.3 ms a frame at 1,970-2,780 draws. My reading, not proven: the Deku Tree pass count matches quazardous' route (228 vs 223). A 7900 XTX at 2560x1440 needs 11.0 ms of GPU time there, close to what the 780M at 720p needed on v2.0.13 (12.7-15.0 ms). That looks more like a fixed per-frame GPU cost on RADV than shading load that scales with the card. Log available on request.