perf(vk): the replay's reserved core on Linux too #445

Merged

HumanBean merged 1 commit from HumanBean/Longshot:perf/replaypin-linux into main 2026-11-14 15:12:40 +00:00

Conversation 1 Commits 1 Files changed 4 +55 -20

HumanBean commented 2026-11-14 14:18:24 +00:00

Owner

• Copy link
• Copy Markdown

Why

On Linux the Market runs slower than it needs to: the host keeps one CPU core free of the game's threads for the replay, but on Linux nothing ever ran on it, so the replay shared cores with the game's threads while that core sat idle. Windows has used it by default all along.

What changed

• host: thread_entry and thread_self in host/posix/win32_posix.c give a thread that registers the process's affinity as the process started, as Windows gives a new thread. A Linux thread inherits the affinity of the thread that makes it, so the back end's threads made on first use inside a pinned replay would otherwise have stayed on the reserved core.
• vk: replay_pin_mask() in gpu/vk/vk_replay.cpp is no longer Windows only.
• Not in upstream: thread_entry's reset and SetThreadAffinityMask share the thread's lock, and the reset is skipped once the thread was pinned. hos_thread_start pins a game thread by its handle right after CreateThread; the new thread's reset, coming second, would have put it back on the reserved core.
• tests: tests/test_reserved_core.py has upstream's checks of both and one of the lock.
• docs: a row for RX_VK_REPLAY_PIN in docs/development.md.

Ported from Hookshot's git.notrexed.dev/Hookshot/Hookshot@b0373aeab0 (https://github.com/NotRexed/Hookshot/pull/2903); the authors are credited in the commit.

Flags and settings

Flag	What it does	Default now	Recommendation	Helps on	Doesn't help on	Untested on
RX_VK_REPLAY_PIN=0	The replay stays on the submitting thread's own processors (the switch existed; on Linux it now has something to turn off)	On (the replay runs on the reserved core), on Windows as before and now on Linux	On by default	Linux, where the replay limits the frame: RTX 3090 and Ryzen 9 7900X below	Windows: no change, it was on already	AMD and Intel GPUs on Linux, the Steam Deck, CPUs with 8 threads or fewer (a run on an RX 580 with an i7-9700K is in progress)

Measurements

Interim: these numbers are from one binary with the change switched off and on, not yet from main against this branch. The binary is a local merge (318acabe) of this branch and other ports under test, each behind a run-time switch; the other ports were switched off in both columns. A build of this branch alone against main, interleaved, with a Kokiri Forest phase, is running and will replace this table.

Baseline: local merge @ 318acabe, RX_VK_REPLAY_PIN=0
Compared: local merge @ 318acabe, RX_VK_REPLAY_PIN unset (on)
Why main wasn't the comparison: the screening run tested several ports on one binary; the branch's own A/B against main follows.
Hardware: RTX 3090, NVIDIA 620.70.06, Ryzen 9 7900X (the game on 12 of its 24 threads: one core complex), 32 GB, CachyOS (Linux 7.3.3), headless sway
Scene: Castle Town Market, day, child Link; 2048x1152, the game's own upscaler, no frame generation, uncapped (HOS_FPS_MAX=240)
Method: each session starts the game on a fresh copy of one save, teleports to the Market gate, stands 10 s, runs 10 s to the fountain square, runs six figure-eights with the camera turning (60 s), then turns the camera at the spot for 10 s. Frame times from RX_VK_FRAME_LOG, fps and draws from the log's status lines in each window. Sessions interleaved with the other arms of the screening; 6 baseline sessions, 3 with the change. Medians of the sessions.
How to reproduce: any save in the Market; RX_VK_REPLAY_PIN=0 against unset, the same route each time.

	merge @ 318acabe, RX_VK_REPLAY_PIN=0 (6 sessions)	merge @ 318acabe, pin on (3 sessions)	Δ
standing at the gate: median frame	14.37 ms (13.84 to 14.77)	13.09 ms (12.82 to 13.31)	-1.28 ms
standing at the gate: fps	67.7	73.7	+9%
running in the square: median frame	16.26 ms (15.89 to 16.80)	15.14 ms (15.13 to 15.36)	-1.12 ms
running in the square: fps	59.6	63.2	+6%
running: p99 frame	29.5 ms	28.4 ms	-1.1 ms
running: frames over 25 ms in 60 s	124	95
running: draws a frame	1742	1708	the same scene
GPU time a frame, running	6.3 ms	6.3 ms	none

RX_VK_REPLAY_PIN=0, running in the square
[hos Presentation Thread] vk: a frame's replay time (ms): submit 12.68, present 0.09, draw 8.09, descriptors 2.85, texture lookups 0.24, uploads 0.03, pipelines 0.40, programs 1.23, commands 3.18, dispatch 0.86, memory sync 0.69, queue submit 0.22, slot wait 0.03

pin on, running in the square
[hos sead::MainThread] vk: replays run on logical processors 0x800800 while they replay (RX_VK_REPLAY_PIN=0: off)
[hos Presentation Thread] vk: a frame's replay time (ms): submit 8.32, present 0.15, draw 4.88, descriptors 1.77, texture lookups 0.49, uploads 0.24, pipelines 0.20, programs 0.73, commands 1.90, dispatch 0.57, memory sync 0.68, queue submit 0.16, slot wait 0.01

Testing

Tested: in the game on Linux (RTX 3090, NVIDIA 620.70.06, CachyOS), the Market route above, 3 sessions with the pin and 6 without on one binary; every session reached the square and ran the whole route, no crash, no device loss. The game-free checks were not run locally; CI runs them.

Not tested: this branch built alone (in progress). Threads that never register with the host and are made inside a pinned replay (the texture decode pools, cap_spare_make, FSR 4 builds, driver threads) keep the reserved core's affinity; upstream has the same gap. Whether any thread ends up there is to be checked from a profiled run before this is marked ready. Kokiri Forest and other areas. AMD and Intel GPUs. Windows (no change expected: the code path there is the same as before).

Needs other testers:

• AMD GPU on Linux (RADV): the Market and Kokiri Forest with and without RX_VK_REPLAY_PIN=0, expecting the same or better fps and no new hitch (request to open)
• Steam Deck: the same, expecting no loss on its 8 threads (request to open)

Screenshots

Nothing on screen.

Risk and rollback

A thread could be left on the reserved core and run slowly there, or a game thread's pin could be lost; both would show as a lower frame rate or hitches on Linux, not as a wrong picture. RX_VK_REPLAY_PIN=0 turns the pin off; the affinity reset of registering threads stays (it only gives a thread the process's own mask).

Reviewer notes

Look first at the lock and the pinned flag in host/posix/win32_posix.c: that part is not upstream's. Left for a follow-up: the thread is moved to the reserved core and back for every replay (two affinity calls a submission), which docs/cpu-profile.md prices at about 1.9 % of a core on the serial threads; keeping it there across back-to-back submissions would save that on Windows too.

Issues

None

Checklist

For everyone

• One topic.
• The title is a Conventional Commit (type(scope): description).
• Rebased on current main.
• python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above). Not run locally: waiting for CI.
• Tested in the game, or what wasn't is named under Testing.
• Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). The test requests are still to open.
• Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. The table is a switch off/on on one binary; the branch against main is running.
• No game files, dumps, build output or generated files.
• third_party/ untouched (a new folder with a PROVENANCE.md instead).
• The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

If applicable

• AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
• Flags noted, and the switch reference updated (docs/development.md, the README).
• A file in docs/tested/ for each new measured run (format in docs/tested-configurations.md; no appended row or assembled view). To add with the branch's own runs.
• A check under tests/ that reads changed source updated in this PR, not weakened.
• Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. Linux: built here in the merge; Windows: CI.
• Docs updated.

🤖 Generated with Claude Code

https://claude.ai/code/session_017vw8e34avQ5cTCWow16MXn

## Why On Linux the Market runs slower than it needs to: the host keeps one CPU core free of the game's threads for the replay, but on Linux nothing ever ran on it, so the replay shared cores with the game's threads while that core sat idle. Windows has used it by default all along. ## What changed - host: `thread_entry` and `thread_self` in `host/posix/win32_posix.c` give a thread that registers the process's affinity as the process started, as Windows gives a new thread. A Linux thread inherits the affinity of the thread that makes it, so the back end's threads made on first use inside a pinned replay would otherwise have stayed on the reserved core. - vk: `replay_pin_mask()` in `gpu/vk/vk_replay.cpp` is no longer Windows only. - Not in upstream: `thread_entry`'s reset and `SetThreadAffinityMask` share the thread's lock, and the reset is skipped once the thread was pinned. `hos_thread_start` pins a game thread by its handle right after `CreateThread`; the new thread's reset, coming second, would have put it back on the reserved core. - tests: `tests/test_reserved_core.py` has upstream's checks of both and one of the lock. - docs: a row for `RX_VK_REPLAY_PIN` in `docs/development.md`. Ported from Hookshot's https://git.notrexed.dev/Hookshot/Hookshot/commit/b0373aeab0038215ec87cd47684ee28c811679c6 (https://github.com/NotRexed/Hookshot/pull/2903); the authors are credited in the commit. ## Flags and settings | Flag | What it does | Default now | Recommendation | Helps on | Doesn't help on | Untested on | |---|---|---|---|---|---|---| | `RX_VK_REPLAY_PIN=0` | The replay stays on the submitting thread's own processors (the switch existed; on Linux it now has something to turn off) | On (the replay runs on the reserved core), on Windows as before and now on Linux | On by default | Linux, where the replay limits the frame: RTX 3090 and Ryzen 9 7900X below | Windows: no change, it was on already | AMD and Intel GPUs on Linux, the Steam Deck, CPUs with 8 threads or fewer (a run on an RX 580 with an i7-9700K is in progress) | ## Measurements **Interim: these numbers are from one binary with the change switched off and on, not yet from main against this branch.** The binary is a local merge (318acabe) of this branch and other ports under test, each behind a run-time switch; the other ports were switched off in both columns. A build of this branch alone against main, interleaved, with a Kokiri Forest phase, is running and will replace this table. Baseline: local merge @ 318acabe, `RX_VK_REPLAY_PIN=0` Compared: local merge @ 318acabe, `RX_VK_REPLAY_PIN` unset (on) Why main wasn't the comparison: the screening run tested several ports on one binary; the branch's own A/B against main follows. Hardware: RTX 3090, NVIDIA 620.70.06, Ryzen 9 7900X (the game on 12 of its 24 threads: one core complex), 32 GB, CachyOS (Linux 7.3.3), headless sway Scene: Castle Town Market, day, child Link; 2048x1152, the game's own upscaler, no frame generation, uncapped (`HOS_FPS_MAX=240`) Method: each session starts the game on a fresh copy of one save, teleports to the Market gate, stands 10 s, runs 10 s to the fountain square, runs six figure-eights with the camera turning (60 s), then turns the camera at the spot for 10 s. Frame times from `RX_VK_FRAME_LOG`, fps and draws from the log's status lines in each window. Sessions interleaved with the other arms of the screening; 6 baseline sessions, 3 with the change. Medians of the sessions. How to reproduce: any save in the Market; `RX_VK_REPLAY_PIN=0` against unset, the same route each time. | | merge @ 318acabe, `RX_VK_REPLAY_PIN=0` (6 sessions) | merge @ 318acabe, pin on (3 sessions) | Δ | |---|---|---|---| | standing at the gate: median frame | 14.37 ms (13.84 to 14.77) | 13.09 ms (12.82 to 13.31) | -1.28 ms | | standing at the gate: fps | 67.7 | 73.7 | +9% | | running in the square: median frame | 16.26 ms (15.89 to 16.80) | 15.14 ms (15.13 to 15.36) | -1.12 ms | | running in the square: fps | 59.6 | 63.2 | +6% | | running: p99 frame | 29.5 ms | 28.4 ms | -1.1 ms | | running: frames over 25 ms in 60 s | 124 | 95 | | | running: draws a frame | 1742 | 1708 | the same scene | | GPU time a frame, running | 6.3 ms | 6.3 ms | none | ``` RX_VK_REPLAY_PIN=0, running in the square [hos Presentation Thread] vk: a frame's replay time (ms): submit 12.68, present 0.09, draw 8.09, descriptors 2.85, texture lookups 0.24, uploads 0.03, pipelines 0.40, programs 1.23, commands 3.18, dispatch 0.86, memory sync 0.69, queue submit 0.22, slot wait 0.03 pin on, running in the square [hos sead::MainThread] vk: replays run on logical processors 0x800800 while they replay (RX_VK_REPLAY_PIN=0: off) [hos Presentation Thread] vk: a frame's replay time (ms): submit 8.32, present 0.15, draw 4.88, descriptors 1.77, texture lookups 0.49, uploads 0.24, pipelines 0.20, programs 0.73, commands 1.90, dispatch 0.57, memory sync 0.68, queue submit 0.16, slot wait 0.01 ``` ## Testing **Tested:** in the game on Linux (RTX 3090, NVIDIA 620.70.06, CachyOS), the Market route above, 3 sessions with the pin and 6 without on one binary; every session reached the square and ran the whole route, no crash, no device loss. The game-free checks were not run locally; CI runs them. **Not tested:** this branch built alone (in progress). Threads that never register with the host and are made inside a pinned replay (the texture decode pools, `cap_spare_make`, FSR 4 builds, driver threads) keep the reserved core's affinity; upstream has the same gap. Whether any thread ends up there is to be checked from a profiled run before this is marked ready. Kokiri Forest and other areas. AMD and Intel GPUs. Windows (no change expected: the code path there is the same as before). **Needs other testers:** - AMD GPU on Linux (RADV): the Market and Kokiri Forest with and without `RX_VK_REPLAY_PIN=0`, expecting the same or better fps and no new hitch (request to open) - Steam Deck: the same, expecting no loss on its 8 threads (request to open) ## Screenshots Nothing on screen. ## Risk and rollback A thread could be left on the reserved core and run slowly there, or a game thread's pin could be lost; both would show as a lower frame rate or hitches on Linux, not as a wrong picture. `RX_VK_REPLAY_PIN=0` turns the pin off; the affinity reset of registering threads stays (it only gives a thread the process's own mask). ## Reviewer notes Look first at the lock and the `pinned` flag in `host/posix/win32_posix.c`: that part is not upstream's. Left for a follow-up: the thread is moved to the reserved core and back for every replay (two affinity calls a submission), which `docs/cpu-profile.md` prices at about 1.9 % of a core on the serial threads; keeping it there across back-to-back submissions would save that on Windows too. ## Issues None ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main`. - [ ] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). Not run locally: waiting for CI. - [x] Tested in the game, or what wasn't is named under Testing. - [ ] Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). The test requests are still to open. - [ ] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. The table is a switch off/on on one binary; the branch against main is running. - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### If applicable - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [x] Flags noted, and the switch reference updated (docs/development.md, the README). - [ ] A file in `docs/tested/` for each new measured run (format in `docs/tested-configurations.md`; no appended row or assembled view). To add with the branch's own runs. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [ ] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. Linux: built here in the merge; Windows: CI. - [x] Docs updated. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_017vw8e34avQ5cTCWow16MXn

HumanBean added 1 commit 2026-11-14 14:18:24 +00:00

perf(vk): the replay's reserved core on Linux too ... 20378ccaf2

The host keeps one core free of the game's threads for the replay (hos_reserved_cpus), but on Linux nothing ran
there with the default synchronous replay: replay_pin_mask() returned 0 off Windows, because a Linux thread
inherits the affinity of the thread that makes it and the back end's threads made on first use inside a pinned
replay would have stayed on that one core.

- host/posix/win32_posix.c: a thread that registers (CreateThread's thread_entry, or thread_self on a std::thread's
  first SetThreadDescription / SetThreadPriority) is given the process's affinity as the process started, as Windows
  gives a new thread.
- gpu/vk/vk_replay.cpp: replay_pin_mask() is no longer Windows only. RX_VK_REPLAY_PIN=0 turns it off, as on Windows.
- tests/test_reserved_core.py: upstream's checks of both, and one of the change below.
- docs/development.md: a row for RX_VK_REPLAY_PIN.

Not in upstream: thread_entry's reset and SetThreadAffinityMask share the thread's lock, and the reset is skipped
once the thread was pinned. hos_thread_start pins a game thread by its handle right after CreateThread; the new
thread's reset, coming second, would have put it back on the reserved core.

Upstream measured (i5-13600KF, RX 9070 XT, RADV, Arch Linux; separate sessions, not an A/B): memory sync 2.23 ->
1.54 ms median, a submit's replay 6.37 -> 5.27 ms, 64.3 -> 69.5 fps. Not measured here: nothing was built or run.

Ported from b0373aeab0
(https://github.com/NotRexed/Hookshot/pull/2903).

Co-authored-by: David Sandner <[email protected]>
Co-Authored-By: Claude Fable 5.2 <[email protected]>
Claude-Session: https://claude.ai/code/session_017vw8e34avQ5cTCWow16MXn

mooki added the

kind

performance

priority

high

labels 2026-11-14 14:57:45 +00:00

HumanBean changed title from WIP: perf(vk): the replay's reserved core on Linux too to perf(vk): the replay's reserved core on Linux too 2026-11-14 15:12:34 +00:00

HumanBean merged commit 55e5599cdd into main 2026-11-14 15:12:40 +00:00

HumanBean deleted branch perf/replaypin-linux 2026-11-14 15:12:41 +00:00

HumanBean referenced this pull request from a commit 2026-11-14 15:12:41 +00:00

perf(vk): the replay's reserved core on Linux too (#445)

jarynclouatre referenced this pull request 2026-11-14 16:50:33 +00:00

fix(vk): on Linux the texture helpers started inside a replay run on every core again #499

HumanBean commented 2026-11-14 17:01:18 +00:00

Author

Owner

• Copy link
• Copy Markdown

Correction to this PR's measurements, and the fair numbers.

The table in the description overstated the gain, and the mistake was in my test setup. My timed sessions confine the game to 12 of the PC's 24 logical processors (CPUs 0-5 and 12-17), but the host's reserved core is chosen from all of them, and here it was CPUs 11 and 23, outside that set. With the pin on, the replay therefore ran on a 13th core the baseline did not have (and was starved whenever a build ran on that side, which gave multi-second frames in some sessions). The description's +9 % standing and +6 % running came from that setup.

Measured again with the reserved core inside the session's own processors (HOS_RESERVE_CORE_MASK=20020: CPUs 5 and 17, so both arms have the same 12 and the game's threads are kept off that core in both):

Baseline: local merge @ 318acabe (this PR's change and other ports, each behind a run-time switch, the others off), RX_VK_REPLAY_PIN=0
Compared: the same binary, pin on
Hardware: RTX 3090, NVIDIA 620.70.06, Ryzen 9 7900X (12 of 24 threads), 32 GB, CachyOS (Linux 7.3.3), headless sway
Scene: Castle Town Market, day, child Link; 2048x1152, the game's own upscaler, uncapped
Method: each session loads a save made at the Market gate, stands 10 s, runs 10 s to the fountain square, runs six figure-eights with the camera turning (60 s), then turns the camera for 10 s; frame times from RX_VK_FRAME_LOG. 3 sessions a side, interleaved (with a third arm). Medians of the sessions, their range in brackets.

	RX_VK_REPLAY_PIN=0 (3 sessions)	pin on (3 sessions)	Δ
standing at the gate: median frame	13.72 ms (13.47 to 13.76)	13.13 ms (12.72 to 13.35)	-0.59 ms, +4.5 % fps
running in the square: median frame	16.14 ms (15.19 to 16.36)	14.89 ms (14.43 to 15.01)	-1.25 ms, +8 % fps
running: p99 frame	28.5 ms	25.4 ms	-3.1 ms
running: frames over 25 ms in 60 s	131	50
turning at the spot: median frame	13.56 ms (12.98 to 14.72)	13.06 ms (12.99 to 13.24)	-0.5 ms
running: draws a frame	1810 / 1692 / 1686	1567 / 1702 / 1760	the same scene (one pin-on session a little lighter)

[hos sead::MainThread] vk: replays run on logical processors 0x20020 while they replay (RX_VK_REPLAY_PIN=0: off)

So the change does help where the replay limits the frame: about +8 % running in the Market and fewer long frames; standing still it is about +4.5 %, not the +9 % the description says. The PC was busier than in the first round (other jobs, some swapping), so the absolute values are a little worse than the description's; the two arms were interleaved.

Still open from the description:

• a build of this commit alone against its parent, with a Kokiri Forest phase (both builds exist; the run is queued behind other work);
• whether any thread made inside a pinned replay is left on the reserved core (not checked yet);
• test requests for AMD on Linux and the Steam Deck (to open);
• a follow-up fix: the reserved core should be chosen within the processors the process may run on (a pinned or containerised game can otherwise get a reserved core outside its own set, as my sessions did). In progress on a separate branch.

🤖 Generated with Claude Code

**Correction to this PR's measurements, and the fair numbers.** The table in the description overstated the gain, and the mistake was in my test setup. My timed sessions confine the game to 12 of the PC's 24 logical processors (CPUs 0-5 and 12-17), but the host's reserved core is chosen from all of them, and here it was CPUs 11 and 23, outside that set. With the pin on, the replay therefore ran on a 13th core the baseline did not have (and was starved whenever a build ran on that side, which gave multi-second frames in some sessions). The description's +9 % standing and +6 % running came from that setup. Measured again with the reserved core inside the session's own processors (`HOS_RESERVE_CORE_MASK=20020`: CPUs 5 and 17, so both arms have the same 12 and the game's threads are kept off that core in both): Baseline: local merge @ 318acabe (this PR's change and other ports, each behind a run-time switch, the others off), `RX_VK_REPLAY_PIN=0` Compared: the same binary, pin on Hardware: RTX 3090, NVIDIA 620.70.06, Ryzen 9 7900X (12 of 24 threads), 32 GB, CachyOS (Linux 7.3.3), headless sway Scene: Castle Town Market, day, child Link; 2048x1152, the game's own upscaler, uncapped Method: each session loads a save made at the Market gate, stands 10 s, runs 10 s to the fountain square, runs six figure-eights with the camera turning (60 s), then turns the camera for 10 s; frame times from `RX_VK_FRAME_LOG`. 3 sessions a side, interleaved (with a third arm). Medians of the sessions, their range in brackets. | | `RX_VK_REPLAY_PIN=0` (3 sessions) | pin on (3 sessions) | Δ | |---|---|---|---| | standing at the gate: median frame | 13.72 ms (13.47 to 13.76) | 13.13 ms (12.72 to 13.35) | -0.59 ms, +4.5 % fps | | running in the square: median frame | 16.14 ms (15.19 to 16.36) | 14.89 ms (14.43 to 15.01) | -1.25 ms, +8 % fps | | running: p99 frame | 28.5 ms | 25.4 ms | -3.1 ms | | running: frames over 25 ms in 60 s | 131 | 50 | | | turning at the spot: median frame | 13.56 ms (12.98 to 14.72) | 13.06 ms (12.99 to 13.24) | -0.5 ms | | running: draws a frame | 1810 / 1692 / 1686 | 1567 / 1702 / 1760 | the same scene (one pin-on session a little lighter) | ``` [hos sead::MainThread] vk: replays run on logical processors 0x20020 while they replay (RX_VK_REPLAY_PIN=0: off) ``` So the change does help where the replay limits the frame: about +8 % running in the Market and fewer long frames; standing still it is about +4.5 %, not the +9 % the description says. The PC was busier than in the first round (other jobs, some swapping), so the absolute values are a little worse than the description's; the two arms were interleaved. Still open from the description: - a build of this commit alone against its parent, with a Kokiri Forest phase (both builds exist; the run is queued behind other work); - whether any thread made inside a pinned replay is left on the reserved core (not checked yet); - test requests for AMD on Linux and the Steam Deck (to open); - a follow-up fix: the reserved core should be chosen within the processors the process may run on (a pinned or containerised game can otherwise get a reserved core outside its own set, as my sessions did). In progress on a separate branch. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

area/accessibility

Barriers for people with disabilities

  

area/audio

Sound and music

  

area/input

Controllers, keyboard, mouse

  

area/install

Installing, updating, building from your game

  

area/menu

In-game menu and settings

  

area/renderer

Vulkan renderer, shaders, effects

  

area/saves

Save files

  

area/upscaling

DLSS, FSR, frame generation

  

good first issue

A good start for a new contributor

  

gpu/amd

AMD GPUs

  

gpu/igpu

Integrated GPUs

  

gpu/intel

Intel GPUs

  

gpu/nvidia

NVIDIA GPUs

  

help wanted

Extra hands or knowledge wanted

  

kind

bug

Something doesn't work as it should

  

kind

chore

Build, CI, dependencies, tidying

  

kind

docs

Documentation

  

kind

feature

A new feature or an improvement

  

kind

performance

Frame rate, frame time, loading, memory

  

kind

question

A question rather than a change

  

needs measurements

Waiting for before/after measurements

  

platform/linux

Linux only

  

platform/steam-deck

Steam Deck

  

platform/windows

Windows only

  

preview

Maintainers: deploy a preview of this PR's website (read its changes first). Removed after the run.

  

priority

critical

Crashes, data loss, or blocks most players

  

priority

high

Important: next in line

  

priority

low

Nice to have

  

status

blocked

Waits on something else first

  

status

confirmed

Reproduced or agreed on

  

status

duplicate

Already reported or proposed

  

status

invalid

Not a problem in this project

  

status

needs-info

Waiting for more information from the reporter

  

status

wontfix

Will not be worked on

  

testing wanted

Wanted: a test on other hardware (posts a test request in #test-requests)

No labels

area/accessibility

area/audio

area/input

area/install

area/menu

area/renderer

area/saves

area/upscaling

good first issue

gpu/amd

gpu/igpu

gpu/intel

gpu/nvidia

help wanted

kind

bug

kind

chore

kind

docs

kind

feature

kind

performance

kind

question

needs measurements

platform/linux

platform/steam-deck

platform/windows

preview

priority

critical

priority

high

priority

low

status

blocked

status

confirmed

status

duplicate

status

invalid

status

needs-info

status

wontfix

testing wanted

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

MagicBeanDev/Longshot!445

No description provided.