WIP: fix(vk): the render thread may leave its core when another program takes it: no 30-40 ms stalls in Castle Town's market #838

Draft

nyannoying wants to merge 2 commits from nyannoying/Longshot:fix/replay-thread-free-to-move into main

pull from: nyannoying/Longshot:fix/replay-thread-free-to-move

merge into: MagicBeanDev:main

MagicBeanDev:main

Conversation 10 Commits 2 Files changed 16 +92 -2

nyannoying commented 2026-11-15 16:56:50 +00:00

Contributor

• Copy link
• Copy Markdown

Type: fix · Risk: medium · Tested on: Windows 11, Arc B580, i5-13600K · Needs: Windows with an AMD or NVIDIA GPU, and a CPU of one core kind (a Ryzen)

Why

With Threaded rendering on (Auto turns it on with 12 or more logical processors, so most desktop PCs), the game's render thread was tied to one CPU core: the core the game keeps free of its own threads. Other programs' threads are not kept off it. On an i5-13600K with an Arc B580, Windows had parked that core's second logical processor, and a priority-15 thread of Intel's PresentMon service (which the Intel Graphics Software overlay runs) held the one left for 30-40 ms at a time. The render thread waited, ready to run, and the frame came 40 ms or more late: regular hitches in Castle Town's market, up to one a second.

See #565 and #597 (periodic stutter and rough frame times on other PCs): whether a render thread held off its one core causes those is not known.

How to reproduce

Seen on: Windows 11 Pro 10.0.29704 (Insider), Intel Arc B580 12 GB, driver 32.0.101.9154, Core i5-13600K, 64 GB; Intel Graphics Software installed (its PresentMon service running)
Settings and switches: Threaded rendering Auto (On here: 20 logical processors); 1280x720 window, render 75% with Lanczos, frame generation off; HOS_FPS_MAX=240 (the frame rate not capped) for the numbers below
Steps: load a save, go to Castle Town's market by day as child Link (the control bridge's teleport Market_Child), stand at the entrance for a minute and watch the frame times (RX_VK_FRAME_LOG=<file> writes one line a frame). The log says vk: the replay thread runs on logical processors 0xc00, kept from the game's threads. Intel's service takes the core only some of the time (every run of one session, none of another), so the program below does the same on demand: it holds the core's two logical processors (10 and 11 on an i5-13600K; the log's mask) at priority 15 for 35 ms of every second. Run core_hog 10,11 35 1000 200 just before loading the save
Expected: steady frame times, about 17 ms here
Actual: a frame of 50-58 ms every second with the program; with Intel's service, 14-37 frames over 40 ms in 40 s

core_hog.c (build: clang -O2 -o core_hog.exe core_hog.c -lwinmm)

// core_hog.c CPUS BUSY_MS PERIOD_MS SECONDS: another program taking the reserved core, on demand. One thread on each logical
// processor in CPUS (a comma list, e.g. 10,11), at priority 15 (time critical in a normal process), busy for BUSY_MS at the
// start of every PERIOD_MS and asleep for the rest, for SECONDS
#include <windows.h>
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef struct {
    int cpu, busy, period, seconds;
} Arg;

static DWORD WINAPI hog(LPVOID p) {
    const Arg* a = (const Arg*)p;
    SetThreadAffinityMask(GetCurrentThread(), (DWORD_PTR)1 << a->cpu);
    SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);
    LARGE_INTEGER f, t0, t;
    QueryPerformanceFrequency(&f);
    QueryPerformanceCounter(&t0);
    for (;;) {
        QueryPerformanceCounter(&t);
        const double ms = (double)(t.QuadPart - t0.QuadPart) * 1000.0 / (double)f.QuadPart;
        if (ms > a->seconds * 1000.0) break;
        const double at = fmod(ms, a->period);
        if (at >= a->busy) Sleep((DWORD)(a->period - at));   // (one sleep to the next period: no wake-ups between)
    }
    return 0;
}

int main(int argc, char** argv) {
    if (argc != 5) {
        fprintf(stderr, "usage: core_hog CPUS BUSY_MS PERIOD_MS SECONDS\n");
        return 2;
    }
    timeBeginPeriod(1);
    static Arg args[64];
    HANDLE th[64];
    int n = 0;
    char* list = _strdup(argv[1]);
    for (char* tok = strtok(list, ","); tok && n < 64; tok = strtok(NULL, ",")) {
        args[n] = (Arg){atoi(tok), atoi(argv[2]), atoi(argv[3]), atoi(argv[4])};
        th[n] = CreateThread(NULL, 0, hog, &args[n], 0, NULL);
        n++;
    }
    WaitForMultipleObjects((DWORD)n, th, TRUE, INFINITE);
    timeEndPeriod(1);
    return 0;
}

What changed

On Windows the render thread keeps its core as its ideal processor, so it runs there whenever it can, and may now run on the other cores of the fastest kind when another program's thread holds that core. The game's own threads are still kept off the core, as before. RX_VK_RT_STRICT_PIN=1 keeps the render thread to the core alone, as before.

• render thread: replay_thread_main() in gpu/vk/vk_replay.cpp sets the affinity to the reserved core plus fastest_kind_cpus() within the process's affinity, and the ideal processor to the reserved core's last logical processor. The log adds vk: the replay thread may run on logical processors 0xfff (the i5-13600K's performance cores)
• fastest_kind_cpus() (new, Windows only, same file): the logical processors of the cores with the highest EfficiencyClass in the thread's processor group, from GetLogicalProcessorInformationEx. A hybrid CPU's performance cores; every core on a CPU of one kind
• docs: RX_VK_RT_STRICT_PIN in docs/development.md
• not changed: Linux (the core alone, as before), and Threaded rendering Off (a submitting thread that moves to the core while it replays, RX_VK_REPLAY_PIN)

Measurements

Verdict: it helps when another program takes the core and costs a little when none does. With a program holding the core 35 ms of every second, the frames over 40 ms go from 40 a run to 0, the average from 55.2 to 57.4 fps and the 1% low from 18.8 to 41.9 fps. With nothing taking it, there were no hitches either way, and the average is 0.5 fps lower (57.5 to 57.0; the 1% low and p99 are unchanged). With a program that wakes on the core every millisecond, it is worse (one run each, see Risks).

Hardware: Windows 11 Pro 10.0.29704, Intel Arc B580 12 GB (driver 32.0.101.9154), Core i5-13600K, 64 GB
Scene: Castle Town's market as child by day, standing at the entrance; 1280x720 window, render 75% with Lanczos, frame generation off, V-Sync Auto, the frame rate not capped (HOS_FPS_MAX=240)
Method: RX_VK_FRAME_LOG frame times, 40 s measured 40 s after the teleport, each run from a fresh start; 3 runs each way, interleaved (before, after, after, before, before, after); the median of the runs. Frames over 40 ms counted per run
How to reproduce: the steps above; core_hog 10,11 35 1000 200 started with the game for the first rows
Baseline: the renderer this PC's game folder loads, built from 690d8446 (main 2b1d38c6 with #443, #446, #459 and #500 merged) with #761's change applied, against the same with this PR's diff applied (built from 59389332, the same diff as f89a017e after the rebase onto main 0557080f). Main's own renderer (aa95d35f, MKWVK_API_VERSION 23) needs a newer game folder than this one (22): built from main it fell back to WebGPU here, and a new game folder means preparing every shader again on this PC. The diff applies to both unchanged

	Before: the base, #761's change applied @ 690d8446	After: this PR @ f89a017e, on the same base
Another program holding the core 35 ms of every 1 s: frames over 40 ms (each run)	40, 40, 40	0, 0, 0
the same: average fps (median of 3)	55.2	57.4
the same: 1% low fps, frame time p99	18.8, 50.85 ms	41.9, 22.41 ms
Nothing else started: frames over 40 ms (each run)	0, 1, 0	0, 0, 0
the same: average fps (median of 3)	57.5	57.0
the same: 1% low fps, frame time p99	41.1, 22.74 ms	42.0, 22.72 ms
A program waking on the core every 1 ms at priority 15 (busy 35 ms of every 1 s), one run each: average fps, frames over 40 ms	54.3, 39	44.6, 7 (one frame of 500 ms)

Earlier, with Intel's service taking the core (a development build: 690d8446 with experiments not in this PR; the same placement set by switches), 3 runs each: frames over 40 ms 15, 37 and 14 before, 0, 0 and 0 after; average 56.5 and 57.9 fps (medians).

(frame times, per run: frames, those over 40 ms, the time they cost over the median frame, average fps, median, p99)
QS-1 frames 2220  >40ms  40  lost 1392 ms (3.5%)  avg 55.3 fps  median 16.76 ms  p99 51.1     before, with core_hog
QS-2 frames 2220  >40ms  40  lost 1402 ms (3.5%)  avg 55.2 fps  median 16.76 ms  p99 50.8
QS-3 frames 2220  >40ms  40  lost 1391 ms (3.5%)  avg 55.1 fps  median 16.78 ms  p99 50.9
QF-1 frames 2280  >40ms   0  lost    0 ms (0.0%)  avg 57.2 fps  median 16.78 ms  p99 22.8     after, with core_hog
QF-2 frames 2340  >40ms   0  lost    0 ms (0.0%)  avg 57.4 fps  median 16.74 ms  p99 22.2
QF-3 frames 2340  >40ms   0  lost    0 ms (0.0%)  avg 57.4 fps  median 16.71 ms  p99 22.4
PS-1 frames 2340  >40ms   0  lost    0 ms (0.0%)  avg 57.3 fps  median 16.71 ms  p99 22.9     before, nothing started
PS-2 frames 2340  >40ms   1  lost   36 ms (0.1%)  avg 57.5 fps  median 16.67 ms  p99 22.7
PS-3 frames 2340  >40ms   0  lost    0 ms (0.0%)  avg 57.8 fps  median 16.61 ms  p99 22.5
PF-1 frames 2280  >40ms   0  lost    0 ms (0.0%)  avg 56.6 fps  median 16.96 ms  p99 23.5     after, nothing started
PF-2 frames 2340  >40ms   0  lost    0 ms (0.0%)  avg 57.0 fps  median 16.89 ms  p99 22.6
PF-3 frames 2280  >40ms   0  lost    0 ms (0.0%)  avg 57.0 fps  median 16.85 ms  p99 22.7
HS-1 frames 2160  >40ms  39  lost 1366 ms (3.4%)  avg 54.3 fps  median 17.06 ms  p99 51.2     before, a hog waking every 1 ms
HF-1 frames 1800  >40ms   7  lost  966 ms (2.4%)  avg 44.6 fps  median 21.66 ms  p99 34.2     after, a hog waking every 1 ms

before: vk: the replay thread runs on logical processors 0xc00, kept from the game's threads
after:  vk: the replay thread runs on logical processors 0xc00, kept from the game's threads (its ideal processor there; free to go to the other fastest cores when another program takes it)
        vk: the replay thread may run on logical processors 0xfff

Flags and settings

One new A/B switch, off.

Flag	What it is	Before this PR	After this PR	Effect	Helps / doesn't help / untested	Recommendation
RX_VK_RT_STRICT_PIN	Windows: the render thread kept to the reserved core alone	(the only behaviour)	unset: free to move to the fastest cores when another program holds its core	=1: the hitches above come back where another program's thread takes the core; 0.5 fps more where none does	=1 helps only where a program wakes on the core very often (the last row)	off: only for testing

Testing

Tested: python -I -B tests/run_all.py with the toolchain's llvm-mingw on PATH: 504 passed, 18 failed, 72 skipped, and the same 18 fail on main 0557080f (tools this PC lacks, a CRLF pipe check, and test_env_on.py naming RX_VK_PRESENT_AFTER_SIGNAL, all on main too). In the game: Windows 11, Arc B580, driver 32.0.101.9154, i5-13600K, the market as above, 14 runs (Measurements); no device lost; the log lines above.
Not tested: AMD and NVIDIA GPUs; a CPU of one core kind (every core then counts as fastest); Linux (no change); Threaded rendering Off (no change).
Must be tested:

• linux: build the renderer (longshot_vk.so) from this branch and run the market by day for 60 s with Threaded rendering On, expecting it to build and the log line vk: the replay thread runs on logical processors ..., kept from the game's threads with no may run line (Test Farm: @Beanstalk linux, build and the market)
• windows, nvidia or amd, a Ryzen: Threaded rendering On, the market by day, 60 s with RX_VK_FRAME_LOG, this PR against RX_VK_RT_STRICT_PIN=1, expecting the log line vk: the replay thread may run on logical processors with every core, and no lower average fps and no more frames over 40 ms than with the switch (Test Farm: @Beanstalk windows, amd or nvidia, a Ryzen, the market against RX_VK_RT_STRICT_PIN=1)

Risks

What could break: when another program's thread runs on the core, the render thread now goes to another performance core, where the game's threads run, instead of waiting. A program that holds the core for a while (Intel's service, core_hog above) costs nothing then. One that wakes on the core very often at a high priority moves the render thread off its core again and again, and there it ran slower than it waited: 44.6 against 54.3 fps with a priority-15 thread waking every millisecond (one run each; the after run also had one 500 ms frame). With nothing on the core it costs 0.5 fps here (57.5 to 57.0). A CPU of one kind: the render thread may go to any core.
Turning it off: RX_VK_RT_STRICT_PIN=1
Compatibility: Nothing changes.

Issues

See #565, #597

Checklist

Everyone

• One topic.
• The title is a Conventional Commit (type(scope): description) of the status line's type.
• Why gives the reason plainly and links the issues that fit (the tracker searched).
• Measurements has a verdict, or one line saying why there is nothing to measure.
• Testing names what was tested, what wasn't, and what must still be tested, where and how.
• Rebased on current main.
• python -I -B tests/run_all.py passes (any failure that also fails on main is named).
• 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.

When it applies

• AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
• Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. Windows: built (llvm-mingw). Linux: not built here (no Linux toolchain on this PC); outside #ifdef _WIN32 the change is one variable and two log lines around the SetThreadAffinityMask call main already makes there. Asked of the Test Farm (Must be tested).
• Numbers from the same PC, scene and settings, at least 2 interleaved runs each, the median reported.
• Switches documented (docs/development.md; the README for a menu row) and shipped at their recommended value.
• A file in docs/tested/ for each new measured run (format in docs/tested-configurations.md).
• Docs updated.

🤖 Generated with Claude Code

**Type:** fix · **Risk:** medium · **Tested on:** Windows 11, Arc B580, i5-13600K · **Needs:** Windows with an AMD or NVIDIA GPU, and a CPU of one core kind (a Ryzen) ## Why With Threaded rendering on (Auto turns it on with 12 or more logical processors, so most desktop PCs), the game's render thread was tied to one CPU core: the core the game keeps free of its own threads. Other programs' threads are not kept off it. On an i5-13600K with an Arc B580, Windows had parked that core's second logical processor, and a priority-15 thread of Intel's PresentMon service (which the Intel Graphics Software overlay runs) held the one left for 30-40 ms at a time. The render thread waited, ready to run, and the frame came 40 ms or more late: regular hitches in Castle Town's market, up to one a second. See #565 and #597 (periodic stutter and rough frame times on other PCs): whether a render thread held off its one core causes those is not known. ## How to reproduce **Seen on:** Windows 11 Pro 10.0.29704 (Insider), Intel Arc B580 12 GB, driver 32.0.101.9154, Core i5-13600K, 64 GB; Intel Graphics Software installed (its PresentMon service running) **Settings and switches:** Threaded rendering Auto (On here: 20 logical processors); 1280x720 window, render 75% with Lanczos, frame generation off; `HOS_FPS_MAX=240` (the frame rate not capped) for the numbers below **Steps:** load a save, go to Castle Town's market by day as child Link (the control bridge's teleport `Market_Child`), stand at the entrance for a minute and watch the frame times (`RX_VK_FRAME_LOG=<file>` writes one line a frame). The log says `vk: the replay thread runs on logical processors 0xc00, kept from the game's threads`. Intel's service takes the core only some of the time (every run of one session, none of another), so the program below does the same on demand: it holds the core's two logical processors (10 and 11 on an i5-13600K; the log's mask) at priority 15 for 35 ms of every second. Run `core_hog 10,11 35 1000 200` just before loading the save **Expected:** steady frame times, about 17 ms here **Actual:** a frame of 50-58 ms every second with the program; with Intel's service, 14-37 frames over 40 ms in 40 s <details><summary>core_hog.c (build: clang -O2 -o core_hog.exe core_hog.c -lwinmm)</summary> ```c // core_hog.c CPUS BUSY_MS PERIOD_MS SECONDS: another program taking the reserved core, on demand. One thread on each logical // processor in CPUS (a comma list, e.g. 10,11), at priority 15 (time critical in a normal process), busy for BUSY_MS at the // start of every PERIOD_MS and asleep for the rest, for SECONDS #include <windows.h> #include <math.h> #include <stdio.h> #include <stdlib.h> #include <string.h> typedef struct { int cpu, busy, period, seconds; } Arg; static DWORD WINAPI hog(LPVOID p) { const Arg* a = (const Arg*)p; SetThreadAffinityMask(GetCurrentThread(), (DWORD_PTR)1 << a->cpu); SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL); LARGE_INTEGER f, t0, t; QueryPerformanceFrequency(&f); QueryPerformanceCounter(&t0); for (;;) { QueryPerformanceCounter(&t); const double ms = (double)(t.QuadPart - t0.QuadPart) * 1000.0 / (double)f.QuadPart; if (ms > a->seconds * 1000.0) break; const double at = fmod(ms, a->period); if (at >= a->busy) Sleep((DWORD)(a->period - at)); // (one sleep to the next period: no wake-ups between) } return 0; } int main(int argc, char** argv) { if (argc != 5) { fprintf(stderr, "usage: core_hog CPUS BUSY_MS PERIOD_MS SECONDS\n"); return 2; } timeBeginPeriod(1); static Arg args[64]; HANDLE th[64]; int n = 0; char* list = _strdup(argv[1]); for (char* tok = strtok(list, ","); tok && n < 64; tok = strtok(NULL, ",")) { args[n] = (Arg){atoi(tok), atoi(argv[2]), atoi(argv[3]), atoi(argv[4])}; th[n] = CreateThread(NULL, 0, hog, &args[n], 0, NULL); n++; } WaitForMultipleObjects((DWORD)n, th, TRUE, INFINITE); timeEndPeriod(1); return 0; } ``` </details> ## What changed On Windows the render thread keeps its core as its ideal processor, so it runs there whenever it can, and may now run on the other cores of the fastest kind when another program's thread holds that core. The game's own threads are still kept off the core, as before. `RX_VK_RT_STRICT_PIN=1` keeps the render thread to the core alone, as before. - render thread: `replay_thread_main()` in `gpu/vk/vk_replay.cpp` sets the affinity to the reserved core plus `fastest_kind_cpus()` within the process's affinity, and the ideal processor to the reserved core's last logical processor. The log adds `vk: the replay thread may run on logical processors 0xfff` (the i5-13600K's performance cores) - `fastest_kind_cpus()` (new, Windows only, same file): the logical processors of the cores with the highest `EfficiencyClass` in the thread's processor group, from `GetLogicalProcessorInformationEx`. A hybrid CPU's performance cores; every core on a CPU of one kind - docs: `RX_VK_RT_STRICT_PIN` in `docs/development.md` - not changed: Linux (the core alone, as before), and Threaded rendering Off (a submitting thread that moves to the core while it replays, `RX_VK_REPLAY_PIN`) ## Measurements **Verdict:** it helps when another program takes the core and costs a little when none does. With a program holding the core 35 ms of every second, the frames over 40 ms go from 40 a run to 0, the average from 55.2 to 57.4 fps and the 1% low from 18.8 to 41.9 fps. With nothing taking it, there were no hitches either way, and the average is 0.5 fps lower (57.5 to 57.0; the 1% low and p99 are unchanged). With a program that wakes on the core every millisecond, it is worse (one run each, see Risks). Hardware: Windows 11 Pro 10.0.29704, Intel Arc B580 12 GB (driver 32.0.101.9154), Core i5-13600K, 64 GB Scene: Castle Town's market as child by day, standing at the entrance; 1280x720 window, render 75% with Lanczos, frame generation off, V-Sync Auto, the frame rate not capped (`HOS_FPS_MAX=240`) Method: `RX_VK_FRAME_LOG` frame times, 40 s measured 40 s after the teleport, each run from a fresh start; 3 runs each way, interleaved (before, after, after, before, before, after); the median of the runs. Frames over 40 ms counted per run How to reproduce: the steps above; `core_hog 10,11 35 1000 200` started with the game for the first rows Baseline: the renderer this PC's game folder loads, built from 690d8446 (main 2b1d38c6 with #443, #446, #459 and #500 merged) with #761's change applied, against the same with this PR's diff applied (built from 59389332, the same diff as f89a017e after the rebase onto main 0557080f). Main's own renderer (aa95d35f, `MKWVK_API_VERSION` 23) needs a newer game folder than this one (22): built from main it fell back to WebGPU here, and a new game folder means preparing every shader again on this PC. The diff applies to both unchanged | | Before: the base, #761's change applied @ 690d8446 | After: this PR @ f89a017e, on the same base | |---|---|---| | Another program holding the core 35 ms of every 1 s: frames over 40 ms (each run) | 40, 40, 40 | 0, 0, 0 | | the same: average fps (median of 3) | 55.2 | 57.4 | | the same: 1% low fps, frame time p99 | 18.8, 50.85 ms | 41.9, 22.41 ms | | Nothing else started: frames over 40 ms (each run) | 0, 1, 0 | 0, 0, 0 | | the same: average fps (median of 3) | 57.5 | 57.0 | | the same: 1% low fps, frame time p99 | 41.1, 22.74 ms | 42.0, 22.72 ms | | A program waking on the core every 1 ms at priority 15 (busy 35 ms of every 1 s), one run each: average fps, frames over 40 ms | 54.3, 39 | 44.6, 7 (one frame of 500 ms) | Earlier, with Intel's service taking the core (a development build: 690d8446 with experiments not in this PR; the same placement set by switches), 3 runs each: frames over 40 ms 15, 37 and 14 before, 0, 0 and 0 after; average 56.5 and 57.9 fps (medians). ``` (frame times, per run: frames, those over 40 ms, the time they cost over the median frame, average fps, median, p99) QS-1 frames 2220 >40ms 40 lost 1392 ms (3.5%) avg 55.3 fps median 16.76 ms p99 51.1 before, with core_hog QS-2 frames 2220 >40ms 40 lost 1402 ms (3.5%) avg 55.2 fps median 16.76 ms p99 50.8 QS-3 frames 2220 >40ms 40 lost 1391 ms (3.5%) avg 55.1 fps median 16.78 ms p99 50.9 QF-1 frames 2280 >40ms 0 lost 0 ms (0.0%) avg 57.2 fps median 16.78 ms p99 22.8 after, with core_hog QF-2 frames 2340 >40ms 0 lost 0 ms (0.0%) avg 57.4 fps median 16.74 ms p99 22.2 QF-3 frames 2340 >40ms 0 lost 0 ms (0.0%) avg 57.4 fps median 16.71 ms p99 22.4 PS-1 frames 2340 >40ms 0 lost 0 ms (0.0%) avg 57.3 fps median 16.71 ms p99 22.9 before, nothing started PS-2 frames 2340 >40ms 1 lost 36 ms (0.1%) avg 57.5 fps median 16.67 ms p99 22.7 PS-3 frames 2340 >40ms 0 lost 0 ms (0.0%) avg 57.8 fps median 16.61 ms p99 22.5 PF-1 frames 2280 >40ms 0 lost 0 ms (0.0%) avg 56.6 fps median 16.96 ms p99 23.5 after, nothing started PF-2 frames 2340 >40ms 0 lost 0 ms (0.0%) avg 57.0 fps median 16.89 ms p99 22.6 PF-3 frames 2280 >40ms 0 lost 0 ms (0.0%) avg 57.0 fps median 16.85 ms p99 22.7 HS-1 frames 2160 >40ms 39 lost 1366 ms (3.4%) avg 54.3 fps median 17.06 ms p99 51.2 before, a hog waking every 1 ms HF-1 frames 1800 >40ms 7 lost 966 ms (2.4%) avg 44.6 fps median 21.66 ms p99 34.2 after, a hog waking every 1 ms before: vk: the replay thread runs on logical processors 0xc00, kept from the game's threads after: vk: the replay thread runs on logical processors 0xc00, kept from the game's threads (its ideal processor there; free to go to the other fastest cores when another program takes it) vk: the replay thread may run on logical processors 0xfff ``` ### Flags and settings One new A/B switch, off. | Flag | What it is | Before this PR | After this PR | Effect | Helps / doesn't help / untested | Recommendation | |---|---|---|---|---|---|---| | `RX_VK_RT_STRICT_PIN` | Windows: the render thread kept to the reserved core alone | (the only behaviour) | unset: free to move to the fastest cores when another program holds its core | `=1`: the hitches above come back where another program's thread takes the core; 0.5 fps more where none does | `=1` helps only where a program wakes on the core very often (the last row) | off: only for testing | ## Testing **Tested:** `python -I -B tests/run_all.py` with the toolchain's llvm-mingw on `PATH`: 504 passed, 18 failed, 72 skipped, and the same 18 fail on main 0557080f (tools this PC lacks, a CRLF pipe check, and `test_env_on.py` naming `RX_VK_PRESENT_AFTER_SIGNAL`, all on main too). In the game: Windows 11, Arc B580, driver 32.0.101.9154, i5-13600K, the market as above, 14 runs (Measurements); no device lost; the log lines above. **Not tested:** AMD and NVIDIA GPUs; a CPU of one core kind (every core then counts as fastest); Linux (no change); Threaded rendering Off (no change). **Must be tested:** - linux: build the renderer (`longshot_vk.so`) from this branch and run the market by day for 60 s with Threaded rendering On, expecting it to build and the log line `vk: the replay thread runs on logical processors ..., kept from the game's threads` with no `may run` line (Test Farm: @Beanstalk linux, build and the market) - windows, nvidia or amd, a Ryzen: Threaded rendering On, the market by day, 60 s with `RX_VK_FRAME_LOG`, this PR against `RX_VK_RT_STRICT_PIN=1`, expecting the log line `vk: the replay thread may run on logical processors` with every core, and no lower average fps and no more frames over 40 ms than with the switch (Test Farm: @Beanstalk windows, amd or nvidia, a Ryzen, the market against RX_VK_RT_STRICT_PIN=1) ## Risks **What could break:** when another program's thread runs on the core, the render thread now goes to another performance core, where the game's threads run, instead of waiting. A program that holds the core for a while (Intel's service, `core_hog` above) costs nothing then. One that wakes on the core very often at a high priority moves the render thread off its core again and again, and there it ran slower than it waited: 44.6 against 54.3 fps with a priority-15 thread waking every millisecond (one run each; the after run also had one 500 ms frame). With nothing on the core it costs 0.5 fps here (57.5 to 57.0). A CPU of one kind: the render thread may go to any core. **Turning it off:** `RX_VK_RT_STRICT_PIN=1` **Compatibility:** Nothing changes. ## Issues See #565, #597 ## Checklist ### Everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`) of the status line's type. - [x] Why gives the reason plainly and links the issues that fit (the tracker searched). - [x] Measurements has a verdict, or one line saying why there is nothing to measure. - [x] Testing names what was tested, what wasn't, and what must still be tested, where and how. - [x] Rebased on current `main`. - [x] `python -I -B tests/run_all.py` passes (any failure that also fails on `main` is named). - [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. ### When it applies - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [ ] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. Windows: built (llvm-mingw). Linux: not built here (no Linux toolchain on this PC); outside `#ifdef _WIN32` the change is one variable and two log lines around the `SetThreadAffinityMask` call main already makes there. Asked of the Test Farm (Must be tested). - [x] Numbers from the same PC, scene and settings, at least 2 interleaved runs each, the median reported. - [x] Switches documented (docs/development.md; the README for a menu row) and shipped at their recommended value. - [x] A file in `docs/tested/` for each new measured run (format in `docs/tested-configurations.md`). - [x] Docs updated. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

nyannoying added 1 commit 2026-11-15 16:56:50 +00:00

fix(vk): the render thread may leave its core when another program takes it: no 30-40 ms stalls in Castle Town's market ... 5938933241

The render thread (Threaded rendering On, Auto's pick with 12 or more logical processors) was kept to the core the host
keeps free of the game's threads, alone. Other programs' threads are not kept off it: on an i5-13600K with an Arc B580,
Windows parked the core's second logical processor, and a priority-15 thread of Intel's PresentMon service (which the
Intel Graphics Software overlay runs) held the one left for 30-40 ms at a time while the render thread waited, ready to
run. 14-37 frames over 40 ms in each 40 s run in the market.

On Windows the render thread now has its ideal processor on that core and may run on the other cores of the fastest kind
(the highest EfficiencyClass: a hybrid CPU's performance cores; every core on a CPU of one kind), within the process's
affinity. RX_VK_RT_STRICT_PIN=1 keeps it to the core alone, as before. Elsewhere nothing changes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Rogasse referenced this pull request 2026-11-15 17:28:44 +00:00

Game: 13-25 real FPS in Castle Town Market on Nightly 189 with RTX 4050 6 GB #813

nyannoying added 1 commit 2026-11-15 17:40:22 +00:00

docs(tested): the render thread's placement, 14 runs in Castle Town's market on an Arc B580 ... ef8beb6701

Before and after this PR's change, interleaved: with a program holding the reserved core 35 ms of every
second, with nothing started, and one pair with a program waking on the core every millisecond.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

nyannoying commented 2026-11-15 17:40:26 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Measured: 3 interleaved runs each way in the market on the base this PC's game folder loads (690d8446 + #761; main's renderer needs a newer game folder). With a program holding the core 35 ms a second: 40 frames over 40 ms a run before, 0 after; 55.2 to 57.4 fps. Nothing started: no hitches either way, 57.5 to 57.0 fps. A program waking on the core every 1 ms at priority 15: worse after (44.6 against 54.3 fps, one run each), now in Risks. 14 docs/tested files added; risk raised to medium.

Measured: 3 interleaved runs each way in the market on the base this PC's game folder loads (690d8446 + #761; main's renderer needs a newer game folder). With a program holding the core 35 ms a second: 40 frames over 40 ms a run before, 0 after; 55.2 to 57.4 fps. Nothing started: no hitches either way, 57.5 to 57.0 fps. A program waking on the core every 1 ms at priority 15: worse after (44.6 against 54.3 fps, one run each), now in Risks. 14 docs/tested files added; risk raised to medium.

nyannoying force-pushed fix/replay-thread-free-to-move from ef8beb6701 to e5f1e40c95 2026-11-15 17:57:37 +00:00 Compare

nyannoying commented 2026-11-15 17:57:45 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Rebased onto main 0557080f (no conflicts; main's three new commits touch none of these files). python -I -B tests/run_all.py: 504 passed, 18 failed, 72 skipped, the same 18 failing on main 0557080f.

Rebased onto main 0557080f (no conflicts; main's three new commits touch none of these files). python -I -B tests/run_all.py: 504 passed, 18 failed, 72 skipped, the same 18 failing on main 0557080f.

nyannoying commented 2026-11-15 17:59:23 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Measurements' columns now name their commits (Before: the base @ 690d8446, After: this PR @ f89a017e). Added the Linux build box, not ticked: no Linux toolchain on this PC, so a Linux build and run is asked of the Test Farm; the PR stays WIP until then.

Measurements' columns now name their commits (Before: the base @ 690d8446, After: this PR @ f89a017e). Added the Linux build box, not ticked: no Linux toolchain on this PC, so a Linux build and run is asked of the Test Farm; the PR stays WIP until then.

nyannoying commented 2026-11-15 17:59:25 +00:00

Author

Contributor

• Copy link
• Copy Markdown

@Beanstalk two runs for this PR, please:

1. linux: build the renderer (longshot_vk.so) from this branch, then stand at the entrance of Castle Town's market by day as child Link for 60 s with Threaded rendering On. Expected: it builds, no device lost, and the log line vk: the replay thread runs on logical processors ..., kept from the game's threads with no may run line after it (Linux keeps the old placement).
2. windows, amd or nvidia GPU, a Ryzen CPU: the same spot for 60 s with RX_VK_FRAME_LOG=<file>, once with this PR as it is and once with RX_VK_RT_STRICT_PIN=1. Expected: the log line vk: the replay thread may run on logical processors listing every core; with this PR, an average fps no lower and no more frames over 40 ms than with the switch.

@Beanstalk two runs for this PR, please: 1. linux: build the renderer (longshot_vk.so) from this branch, then stand at the entrance of Castle Town's market by day as child Link for 60 s with Threaded rendering On. Expected: it builds, no device lost, and the log line `vk: the replay thread runs on logical processors ..., kept from the game's threads` with no `may run` line after it (Linux keeps the old placement). 2. windows, amd or nvidia GPU, a Ryzen CPU: the same spot for 60 s with `RX_VK_FRAME_LOG=<file>`, once with this PR as it is and once with `RX_VK_RT_STRICT_PIN=1`. Expected: the log line `vk: the replay thread may run on logical processors` listing every core; with this PR, an average fps no lower and no more frames over 40 ms than with the switch.

👍 1

Beanstalk commented 2026-11-15 17:59:28 +00:00

Member

• Copy link
• Copy Markdown

@nyannoying only members of BigBeans can start the farm. One of them can approve this request by reacting 👍 to it.

@nyannoying only members of `BigBeans` can start the farm. One of them can approve this request by reacting 👍 to it.

👍 1

Beanstalk commented 2026-11-15 18:01:53 +00:00

Member

• Copy link
• Copy Markdown

Beanstalk test farm

Commit 8015c9a · tier reviewed · approved by futondestroyer · dashboard

What will be tested · AI plan (gpt-6.1-terra)

The plan compares main and the PR in child Link’s Castle Town Market for 60 seconds after warm-up, with threaded rendering enabled. It measures mean FPS, median and p99 frame time, hitches over 50 ms, crashes and placement logs; device loss, a missing reserved-core log, a Linux “may run” log or a substantial performance regression fails. The Linux target is currently offline and will wait for a tester. This farm schema skips Windows gameplay, so the requested Windows runs and direct default-versus-strict comparison cannot be represented; it also cannot count frames over 40 ms or guarantee daytime. Ryzen coverage remains outstanding, and a quiet run would not prove the contention fix. No tester online now matches linux: that target waits for one.

• Where: linux (1 report).
• market-threaded: from a new save (settings frame_rate_cap=6, frame_generation=0; switches RX_VK_ASYNC=1, RX_VK_RECORDER=thread), then teleport to Market, measure market for 60 s (after 40 s warm-up); 2 runs on each side.
• Measured: crashes, frame times, stutters and hitches, draws and frame rate, the game's log.
• The PR fails if: it crashes; or frame rate is more than 10% below main; or frame time (p99) is more than 15% above main; or forbidden log lines is above 0; or expected log lines missing is above 0.
• Time: about 31 min of game runs per tester (4 game starts), plus the two builds.

Started.

Target	Reports	Crash	Frame p99 (ms) vs main	VRAM peak (MB) vs main	Result
linux	0/1	—	—	—	queued

<!-- beanstalk:sticky --> ### Beanstalk test farm Commit `8015c9a` · tier **reviewed** · approved by futondestroyer · [dashboard](https://beanstalk.magicbean.dev/prs/838) **What will be tested** · AI plan (`gpt-6.1-terra`) The plan compares main and the PR in child Link’s Castle Town Market for 60 seconds after warm-up, with threaded rendering enabled. It measures mean FPS, median and p99 frame time, hitches over 50 ms, crashes and placement logs; device loss, a missing reserved-core log, a Linux “may run” log or a substantial performance regression fails. The Linux target is currently offline and will wait for a tester. This farm schema skips Windows gameplay, so the requested Windows runs and direct default-versus-strict comparison cannot be represented; it also cannot count frames over 40 ms or guarantee daytime. Ryzen coverage remains outstanding, and a quiet run would not prove the contention fix. No tester online now matches linux: that target waits for one. - **Where:** linux (1 report). - **market-threaded:** from a new save (settings frame_rate_cap=6, frame_generation=0; switches `RX_VK_ASYNC=1`, `RX_VK_RECORDER=thread`), then teleport to Market, measure market for 60 s (after 40 s warm-up); 2 runs on each side. - **Measured:** crashes, frame times, stutters and hitches, draws and frame rate, the game's log. - **The PR fails if:** it crashes; or frame rate is more than 10% below main; or frame time (p99) is more than 15% above main; or forbidden log lines is above 0; or expected log lines missing is above 0. - **Time:** about 31 min of game runs per tester (4 game starts), plus the two builds. Started. | Target | Reports | Crash | Frame p99 (ms) vs main | VRAM peak (MB) vs main | Result | | --- | --- | --- | --- | --- | --- | | linux | 0/1 | — | — | — | queued |

Beanstalk added the

beanstalk: approved @ e5f1e40

label 2026-11-15 18:02:16 +00:00

futondestroyer commented 2026-11-15 18:08:18 +00:00

Member

• Copy link
• Copy Markdown

/beanstalk plan Preserve the author's Linux test and add Windows gameplay for head e5f1e40c95. Windows gameplay is now opt-in in Beanstalk main (PR 7); this volunteer is running dev-416730c with isolated_gameplay enabled.

Linux: build and measure 60 s in child daytime Castle Town Market with threaded rendering On, checking the reserved-core placement log, no Windows-only "may run" line and no device loss.

Windows: target Windows NVIDIA, without pinning a GPU model or requiring Ryzen, so this RTX 4070 / i7-13700F PC can contribute. Use isolated disposable new-game saves and the child daytime Market. Threaded rendering On, frame generation off, uncapped, otherwise identical settings. Measure 60 s after warm-up, at least two interleaved runs per arm. Compare main with the PR and, using a PR-only switch matrix if supported, PR default against RX_VK_RT_STRICT_PIN=1. Report mean fps, median/p99 frame time, hitches, crashes/device loss and placement logs. State explicitly if frames over 40 ms, direct switch comparison, or other requested coverage cannot be represented. Do not substitute a title-only test for Windows gameplay.

This Intel hybrid CPU supplies supplemental Windows/NVIDIA coverage; it does not complete the author's separate Ryzen/single-core-kind request. Do not run the comment's external core_hog program. A quiet run does not prove the contention fix. Keep saves, dumps and generated game builds local; only normal permitted farm reports may be uploaded.

/beanstalk plan Preserve the author's Linux test and add Windows gameplay for head e5f1e40c9589958b3ee82991d7ad51991528e691. Windows gameplay is now opt-in in Beanstalk main (PR 7); this volunteer is running dev-416730c with isolated_gameplay enabled. Linux: build and measure 60 s in child daytime Castle Town Market with threaded rendering On, checking the reserved-core placement log, no Windows-only "may run" line and no device loss. Windows: target Windows NVIDIA, without pinning a GPU model or requiring Ryzen, so this RTX 4070 / i7-13700F PC can contribute. Use isolated disposable new-game saves and the child daytime Market. Threaded rendering On, frame generation off, uncapped, otherwise identical settings. Measure 60 s after warm-up, at least two interleaved runs per arm. Compare main with the PR and, using a PR-only switch matrix if supported, PR default against RX_VK_RT_STRICT_PIN=1. Report mean fps, median/p99 frame time, hitches, crashes/device loss and placement logs. State explicitly if frames over 40 ms, direct switch comparison, or other requested coverage cannot be represented. Do not substitute a title-only test for Windows gameplay. This Intel hybrid CPU supplies supplemental Windows/NVIDIA coverage; it does not complete the author's separate Ryzen/single-core-kind request. Do not run the comment's external core_hog program. A quiet run does not prove the contention fix. Keep saves, dumps and generated game builds local; only normal permitted farm reports may be uploaded.

👀 1

mooki referenced this pull request 2026-11-15 18:42:19 +00:00

feat(test): pin test requests and results to commits #71

mooki referenced this pull request 2026-11-15 18:42:23 +00:00

ci: add an owner-approved hardware fixture pilot #100

HumanBean force-pushed fix/replay-thread-free-to-move from e5f1e40c95 to 8015c9a8c7 2026-11-15 18:46:09 +00:00 Compare

Beanstalk removed the

beanstalk: approved @ e5f1e40

label 2026-11-15 18:46:11 +00:00

HumanBean commented 2026-11-15 18:47:12 +00:00

Owner

• Copy link
• Copy Markdown

Rebased onto main @ 7bacf846: no conflicts. No tests were run here; the test boxes stay yours.

Rebased onto `main` @ 7bacf846: no conflicts. No tests were run here; the test boxes stay yours.

futondestroyer commented 2026-11-15 19:11:55 +00:00

Member

• Copy link
• Copy Markdown

@Beanstalk Preserve the author's Linux test and add Windows gameplay for head 8015c9a8c7. Windows gameplay is now opt-in in Beanstalk main (PR 7); this volunteer is running dev-416730c with isolated_gameplay enabled.

Linux: build and measure 60 s in child daytime Castle Town Market with threaded rendering On, checking the reserved-core placement log, no Windows-only "may run" line and no device loss.

Windows: target Windows NVIDIA, without pinning a GPU model or requiring Ryzen, so this RTX 4070 / i7-13700F PC can contribute. Use isolated disposable new-game saves and the child daytime Market. Threaded rendering On, frame generation off, uncapped, otherwise identical settings. Measure 60 s after warm-up, at least two interleaved runs per arm. Compare main with the PR and, using a PR-only switch matrix if supported, PR default against RX_VK_RT_STRICT_PIN=1. Report mean fps, median/p99 frame time, hitches, crashes/device loss and placement logs. State explicitly if frames over 40 ms, direct switch comparison, or other requested coverage cannot be represented. Do not substitute a title-only test for Windows gameplay.

This Intel hybrid CPU supplies supplemental Windows/NVIDIA coverage; it does not complete the author's separate Ryzen/single-core-kind request. Do not run the comment's external core_hog program. A quiet run does not prove the contention fix. Keep saves, dumps and generated game builds local; only normal permitted farm reports may be uploaded.

@Beanstalk Preserve the author's Linux test and add Windows gameplay for head 8015c9a8c7a1d5504d9d6bef16266c97f39f60a7. Windows gameplay is now opt-in in Beanstalk main (PR 7); this volunteer is running dev-416730c with isolated_gameplay enabled. Linux: build and measure 60 s in child daytime Castle Town Market with threaded rendering On, checking the reserved-core placement log, no Windows-only "may run" line and no device loss. Windows: target Windows NVIDIA, without pinning a GPU model or requiring Ryzen, so this RTX 4070 / i7-13700F PC can contribute. Use isolated disposable new-game saves and the child daytime Market. Threaded rendering On, frame generation off, uncapped, otherwise identical settings. Measure 60 s after warm-up, at least two interleaved runs per arm. Compare main with the PR and, using a PR-only switch matrix if supported, PR default against RX_VK_RT_STRICT_PIN=1. Report mean fps, median/p99 frame time, hitches, crashes/device loss and placement logs. State explicitly if frames over 40 ms, direct switch comparison, or other requested coverage cannot be represented. Do not substitute a title-only test for Windows gameplay. This Intel hybrid CPU supplies supplemental Windows/NVIDIA coverage; it does not complete the author's separate Ryzen/single-core-kind request. Do not run the comment's external core_hog program. A quiet run does not prove the contention fix. Keep saves, dumps and generated game builds local; only normal permitted farm reports may be uploaded.

👀 1

Beanstalk added the

beanstalk: approved @ 8015c9a

label 2026-11-15 19:12:11 +00:00

nyannoying commented 2026-11-15 19:45:28 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Tests on HumanBean's rebase (head 8015c9a8, on main 7bacf846): python -I -B tests/run_all.py with the toolchain's llvm-mingw on PATH gives 515 passed, 19 failed, 75 skipped. The 19 are the ones that fail on main 7bacf846 alone on this PC: test_appimage_player_build, test_auto_handheld, test_cpp_preflight, test_crash_dialog, test_env_on, test_fpx_sticky, test_lift_cleanup_error, test_linux_preflight, test_make_game_cache, test_make_game_prepare, test_missing_nup, test_oot_state_tap, test_options_budget_once, test_readback_late, test_spawn_emit, test_tested_configurations, test_vk_occlusion_queries, test_vk_pgo, test_walk_key. test_env_on.py names only main's RX_VK_PRESENT_AFTER_SIGNAL, not this PR's RX_VK_RT_STRICT_PIN.

The rebase left the diff unchanged (git range-diff: both commits identical to f89a017e and e5f1e40c), so the Measurements still stand. Nothing was pushed, so the farm's approval at 8015c9a still holds. The Linux box waits for the farm's Linux report.

Tests on HumanBean's rebase (head 8015c9a8, on main 7bacf846): `python -I -B tests/run_all.py` with the toolchain's llvm-mingw on `PATH` gives 515 passed, 19 failed, 75 skipped. The 19 are the ones that fail on main 7bacf846 alone on this PC: test_appimage_player_build, test_auto_handheld, test_cpp_preflight, test_crash_dialog, test_env_on, test_fpx_sticky, test_lift_cleanup_error, test_linux_preflight, test_make_game_cache, test_make_game_prepare, test_missing_nup, test_oot_state_tap, test_options_budget_once, test_readback_late, test_spawn_emit, test_tested_configurations, test_vk_occlusion_queries, test_vk_pgo, test_walk_key. `test_env_on.py` names only main's `RX_VK_PRESENT_AFTER_SIGNAL`, not this PR's `RX_VK_RT_STRICT_PIN`. The rebase left the diff unchanged (`git range-diff`: both commits identical to f89a017e and e5f1e40c), so the Measurements still stand. Nothing was pushed, so the farm's approval at 8015c9a still holds. The Linux box waits for the farm's Linux report.

Some checks failed

Hide checks

Third-party parts / The same as upstream (pull_request) Has been skipped

Details

CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been skipped

Details

CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been skipped

Details

CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been skipped

Details

Website / Website on Cloudflare (pull_request) Has been skipped

Details

CI / Workflow lint (actionlint) (pull_request) Successful in 9s

Details

Website / Website on Cloudflare (pull_request_target) Has been skipped

Details

PR description / Description follows the template (pull_request_target) Successful in 4s

Details

CI / Conventional Commit title (pull_request) Successful in 3s

Details

beanstalk/approval approved by futondestroyer (reviewed)

Details

beanstalk/linux 0/1 pass, 0 running, 1 queued

Details

Guide screenshots / Guide images and local UI source review (pull_request) Failing after 5s

Details

Third-party parts / As their notes say (pull_request) Successful in 9s

Details

This pull request is marked as a work in progress.

This branch is out-of-date with the base branch

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u 'fix/replay-thread-free-to-move:nyannoying-fix/replay-thread-free-to-move'

git switch 'nyannoying-fix/replay-thread-free-to-move'

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/tooling

Developer tools: scripts, CI, build and release tooling

  

area/upscaling

DLSS, FSR, frame generation

  

beanstalk: approved @ 1697603

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 2c5a62e

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 4fd82b7

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 64d6d09

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 6f91fae

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 70a78f9

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 8015c9a

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 8d361dc

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 9d8356e

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ abf2227

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ d82f202

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ e5f1e40

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ ee8ab5f

Set by Beanstalk for show; the farm's database is what counts

  

ci: approved

A maintainer approved CircleCI for this fork PR (sticky; removed after 14 quiet days)

  

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

Affects Linux (a change for every system carries both Windows and Linux)

  

platform/macos

macOS (Apple silicon or Intel Macs)

  

platform/steam-deck

Steam Deck

  

platform/windows

Affects Windows (a change for every system carries both Windows and Linux)

  

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

  

regression

Worked in an earlier build, broken in a newer one: highest priority, above other bugs

  

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)

  

ci: approved

No labels

area/accessibility

area/audio

area/input

area/install

area/menu

area/renderer

area/saves

area/tooling

area/upscaling

beanstalk: approved @ 1697603

beanstalk: approved @ 2c5a62e

beanstalk: approved @ 4fd82b7

beanstalk: approved @ 64d6d09

beanstalk: approved @ 6f91fae

beanstalk: approved @ 70a78f9

beanstalk: approved @ 8015c9a

beanstalk: approved @ 8d361dc

beanstalk: approved @ 9d8356e

beanstalk: approved @ abf2227

beanstalk: approved @ d82f202

beanstalk: approved @ e5f1e40

beanstalk: approved @ ee8ab5f

ci: approved

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/macos

platform/steam-deck

platform/windows

preview

priority

critical

priority

high

priority

low

regression

status

blocked

status

confirmed

status

duplicate

status

invalid

status

needs-info

status

wontfix

testing wanted

ci: approved

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

4 participants

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!838

No description provided.