fix(host): a thread lowered right after it is created runs lowered on Linux #496

Open

zeldaootr wants to merge 2 commits from zeldaootr/Longshot:posix-thread-priority-before-start into main

pull from: zeldaootr/Longshot:posix-thread-priority-before-start

merge into: MagicBeanDev:main

MagicBeanDev:main

Conversation 3 Commits 2 Files changed 2 +95 -1

zeldaootr commented 2026-11-14 16:47:02 +00:00

Contributor

• Copy link
• Copy Markdown

Type: fix · Risk: low · Tested on: Linux x86-64 (game-free); Steam Deck OLED, SteamOS 3.9.5, RADV (a tester's run) · Needs: none

Why

On Linux and the Steam Deck, a thread whose priority is lowered right after it is created can keep the normal priority. That is how the game lowers OoT's background OptimizeChangeBank thread (and any HOS_PRIO lowering), so when it happens that thread competes with the renderer and the driver for the CPU, which the lowering exists to stop.

How to reproduce

Seen on: Linux x86-64 (Ubuntu 24.04), game-free; not seen in the game (see Testing)
Settings and switches: defaults
Steps: on main aa95d35f with this PR's test added (cc676b23), run python -I -B tests/test_posix_thread_priority.py (not under nice): it builds the real host/posix/win32_posix.c and lowers 20 threads with THREAD_PRIORITY_LOWEST straight after CreateThread
Expected: each thread runs at nice 10
Actual: FAIL: 20 of 20 threads lowered right after CreateThread kept the normal priority

What changed

SetThreadPriority on Linux now waits for a just-created thread to get its kernel id before lowering it, instead of dropping the lowering, so a thread lowered at creation runs lowered.

• posix host: SetThreadPriority() in host/posix/win32_posix.c skipped setpriority while the thread had no kernel id yet (t->tid == 0). A thread fresh from CreateThread has none until it first runs, and hos_thread_start -> hos_thread_pin (host/hos_thread.c) lowers it straight away, so the lowering was dropped without a word. It now yields until the id is there (or the thread has ended), as GetThreadId() already does, when there is a lowering to apply.
• tests: tests/test_posix_thread_priority.py builds the real host/posix/win32_posix.c with a fixture that creates a thread, lowers it at once with THREAD_PRIORITY_LOWEST and has the thread read its own nice value, 20 times. It skips itself when the test process already runs at nice 10 or more.

Measurements

Verdict: fixed in the game-free test (0 of 20 threads lowered on main, 20 of 20 with this PR, two interleaved rounds); no change on a tester's Steam Deck, where the race was not lost without the PR either (nice 10 both ways, fps within the run-to-run spread).

Hardware: Linux x86-64 server (Ubuntu 24.04), no GPU or game used; gcc 13.3, clang 23.1.5
Scene: no game: the game-free check
Method: python3 -I -B tests/test_posix_thread_priority.py at the test-only commit cc676b23 (main aa95d35f plus the test) and at 6218c00b, twice each, alternating, not under nice
How to reproduce: check out each commit and run the command above

	Before: main @ aa95d35f (with the test, cc676b23)	After: this PR @ 6218c00b
threads lowered right after CreateThread that run at nice 10 (both rounds the same)	0 of 20	20 of 20

cc676b23 r1: FAIL: 20 of 20 threads lowered right after CreateThread kept the normal priority (exit 1)
6218c00b r1: PASS: a thread lowered right after CreateThread runs lowered (nice 10) (exit 0)
cc676b23 r2: FAIL: 20 of 20 threads lowered right after CreateThread kept the normal priority (exit 1)
6218c00b r2: PASS: a thread lowered right after CreateThread runs lowered (nice 10) (exit 0)

In the game, dukenheimer's Steam Deck run for test request T-YHUH (pass; #496 (comment)): this PR's head 7fb4e2c1 (on main 543846eb, the same change) against the same build with this PR's merge reverted, Steam Deck OLED (SteamOS 3.9.5, Mesa 26.2.0-devel, stock clocks, Game Mode), a moving Kokiri route, two runs each, interleaved. OptimizeChangeBank ran at nice 10 in every sample with and without this PR: in both starts without it the new thread already had its id when SetThreadPriority ran. Real fps 13.1 and 12.8 with it, 13.0 and 13.5 without (medians 12.95 and 13.25, inside the 12.8 to 13.5 spread of the series).

Flags and settings

None

Testing

Tested: Linux x86-64, game-free. The new test fails on the test-only commit cc676b23 and passes at 6218c00b (this branch rebased onto main aa95d35f), twice each, alternating, and under tests/run_all.py with g++ 13.3 and with clang 23.1.5 as CXX at both commits. At the tip the 11 checks that read host/posix/win32_posix.c or the new test: 10 passed, and test_mods_size_table failed as it does on main aa95d35f. Before the rebase the same at 9f641552 and 27113be7 (main 7ff5256e). Steam Deck: dukenheimer's run for T-YHUH, in Measurements: nice 10 with and without this PR, fps unchanged within the spread.

Not tested: A start where the race is lost in the game: none was seen (2 of 2 starts on the tester's Deck kept the lowering without this PR), so how often a player hits it is unknown; a slower or busier start is where it would show. A Linux desktop run (welcome, not required). HOS_PRIO lowerings take the same path and were not tried. Windows is not affected: the file is the POSIX layer, not built on Windows.

Must be tested: None

Risks

What could break: SetThreadPriority now yields until a new thread has its id, as GetThreadId does; a thread that never starts would have hung that call already (CREATE_SUSPENDED is not supported and starts the thread at once). Only lowerings wait. A lowered background thread gets less CPU on Linux when the race would have been lost: the intended behaviour and what Windows already does, but on a Deck it could slow whatever that thread does if it matters for frame pacing.

Turning it off: HOS_OCB_NORMAL=1 keeps OptimizeChangeBank at normal priority; otherwise revert the commit.

Compatibility: Nothing changes: no save, option or cache is touched.

Issues

None filed. Note for reviewers: this PR's own test skips itself in a process at nice 10 or more (a run_all.py under nice -n 10 reports it as passed while it skipped); the results above come from runs without nice.

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. Onto main aa95d35f, no conflict; the test and fix commits are the same changes as before (git patch-id).
• python -I -B tests/run_all.py passes (any failure that also fails on main is named). The full suite on main aa95d35f (Linux, g++ 13.3, the Vulkan headers set): 528 passed, 15 failed, 50 skipped; on this branch the new test and the checks that read the changed file ran, with no failure that main does not have (see Testing). The 15 that fail on main: test_appimage_player_build, test_bake_portability, test_cpm_discovery, test_crash_dialog, test_env_on, test_lift_cache, test_lift_cleanup_error, test_make_game_cache, test_mods_size_table, test_options_budget_once, test_pipeline_tour, test_readback_late, test_vk_pgo, test_walk_key and nx2/test_texture_init_barrier.py.
• 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.
• Numbers from the same PC, scene and settings, at least 2 interleaved runs each, the median reported.
• A game-free test added for the fix, failing on main and passing here.

**Type:** fix · **Risk:** low · **Tested on:** Linux x86-64 (game-free); Steam Deck OLED, SteamOS 3.9.5, RADV (a tester's run) · **Needs:** none ## Why On Linux and the Steam Deck, a thread whose priority is lowered right after it is created can keep the normal priority. That is how the game lowers OoT's background `OptimizeChangeBank` thread (and any `HOS_PRIO` lowering), so when it happens that thread competes with the renderer and the driver for the CPU, which the lowering exists to stop. ## How to reproduce **Seen on:** Linux x86-64 (Ubuntu 24.04), game-free; not seen in the game (see Testing) **Settings and switches:** defaults **Steps:** on `main` aa95d35f with this PR's test added (cc676b23), run `python -I -B tests/test_posix_thread_priority.py` (not under `nice`): it builds the real `host/posix/win32_posix.c` and lowers 20 threads with `THREAD_PRIORITY_LOWEST` straight after `CreateThread` **Expected:** each thread runs at nice 10 **Actual:** `FAIL: 20 of 20 threads lowered right after CreateThread kept the normal priority` ## What changed `SetThreadPriority` on Linux now waits for a just-created thread to get its kernel id before lowering it, instead of dropping the lowering, so a thread lowered at creation runs lowered. - posix host: `SetThreadPriority()` in `host/posix/win32_posix.c` skipped `setpriority` while the thread had no kernel id yet (`t->tid == 0`). A thread fresh from `CreateThread` has none until it first runs, and `hos_thread_start` -> `hos_thread_pin` (`host/hos_thread.c`) lowers it straight away, so the lowering was dropped without a word. It now yields until the id is there (or the thread has ended), as `GetThreadId()` already does, when there is a lowering to apply. - tests: `tests/test_posix_thread_priority.py` builds the real `host/posix/win32_posix.c` with a fixture that creates a thread, lowers it at once with `THREAD_PRIORITY_LOWEST` and has the thread read its own nice value, 20 times. It skips itself when the test process already runs at nice 10 or more. ## Measurements **Verdict:** fixed in the game-free test (0 of 20 threads lowered on `main`, 20 of 20 with this PR, two interleaved rounds); no change on a tester's Steam Deck, where the race was not lost without the PR either (nice 10 both ways, fps within the run-to-run spread). Hardware: Linux x86-64 server (Ubuntu 24.04), no GPU or game used; gcc 13.3, clang 23.1.5 Scene: no game: the game-free check Method: `python3 -I -B tests/test_posix_thread_priority.py` at the test-only commit cc676b23 (main aa95d35f plus the test) and at 6218c00b, twice each, alternating, not under `nice` How to reproduce: check out each commit and run the command above | | Before: main @ aa95d35f (with the test, cc676b23) | After: this PR @ 6218c00b | |---|---|---| | threads lowered right after `CreateThread` that run at nice 10 (both rounds the same) | 0 of 20 | 20 of 20 | ``` cc676b23 r1: FAIL: 20 of 20 threads lowered right after CreateThread kept the normal priority (exit 1) 6218c00b r1: PASS: a thread lowered right after CreateThread runs lowered (nice 10) (exit 0) cc676b23 r2: FAIL: 20 of 20 threads lowered right after CreateThread kept the normal priority (exit 1) 6218c00b r2: PASS: a thread lowered right after CreateThread runs lowered (nice 10) (exit 0) ``` In the game, dukenheimer's Steam Deck run for test request T-YHUH (pass; https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/496#issuecomment-20373): this PR's head 7fb4e2c1 (on main 543846eb, the same change) against the same build with this PR's merge reverted, Steam Deck OLED (SteamOS 3.9.5, Mesa 26.2.0-devel, stock clocks, Game Mode), a moving Kokiri route, two runs each, interleaved. `OptimizeChangeBank` ran at nice 10 in every sample with and without this PR: in both starts without it the new thread already had its id when `SetThreadPriority` ran. Real fps 13.1 and 12.8 with it, 13.0 and 13.5 without (medians 12.95 and 13.25, inside the 12.8 to 13.5 spread of the series). ### Flags and settings None ## Testing **Tested:** Linux x86-64, game-free. The new test fails on the test-only commit cc676b23 and passes at 6218c00b (this branch rebased onto `main` aa95d35f), twice each, alternating, and under `tests/run_all.py` with g++ 13.3 and with clang 23.1.5 as `CXX` at both commits. At the tip the 11 checks that read `host/posix/win32_posix.c` or the new test: 10 passed, and `test_mods_size_table` failed as it does on `main` aa95d35f. Before the rebase the same at 9f641552 and 27113be7 (main 7ff5256e). Steam Deck: dukenheimer's run for T-YHUH, in Measurements: nice 10 with and without this PR, fps unchanged within the spread. **Not tested:** A start where the race is lost in the game: none was seen (2 of 2 starts on the tester's Deck kept the lowering without this PR), so how often a player hits it is unknown; a slower or busier start is where it would show. A Linux desktop run (welcome, not required). `HOS_PRIO` lowerings take the same path and were not tried. Windows is not affected: the file is the POSIX layer, not built on Windows. **Must be tested:** None ## Risks **What could break:** `SetThreadPriority` now yields until a new thread has its id, as `GetThreadId` does; a thread that never starts would have hung that call already (`CREATE_SUSPENDED` is not supported and starts the thread at once). Only lowerings wait. A lowered background thread gets less CPU on Linux when the race would have been lost: the intended behaviour and what Windows already does, but on a Deck it could slow whatever that thread does if it matters for frame pacing. **Turning it off:** `HOS_OCB_NORMAL=1` keeps `OptimizeChangeBank` at normal priority; otherwise revert the commit. **Compatibility:** Nothing changes: no save, option or cache is touched. ## Issues None filed. Note for reviewers: this PR's own test skips itself in a process at nice 10 or more (a `run_all.py` under `nice -n 10` reports it as passed while it skipped); the results above come from runs without `nice`. ## 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`. Onto main aa95d35f, no conflict; the test and fix commits are the same changes as before (`git patch-id`). - [x] `python -I -B tests/run_all.py` passes (any failure that also fails on `main` is named). The full suite on main aa95d35f (Linux, g++ 13.3, the Vulkan headers set): 528 passed, 15 failed, 50 skipped; on this branch the new test and the checks that read the changed file ran, with no failure that `main` does not have (see Testing). The 15 that fail on main: `test_appimage_player_build`, `test_bake_portability`, `test_cpm_discovery`, `test_crash_dialog`, `test_env_on`, `test_lift_cache`, `test_lift_cleanup_error`, `test_make_game_cache`, `test_mods_size_table`, `test_options_budget_once`, `test_pipeline_tour`, `test_readback_late`, `test_vk_pgo`, `test_walk_key` and `nx2/test_texture_init_barrier.py`. - [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. - [x] Numbers from the same PC, scene and settings, at least 2 interleaved runs each, the median reported. - [x] A game-free test added for the fix, failing on `main` and passing here.

zeldaootr added 2 commits 2026-11-14 16:47:02 +00:00

test: SetThreadPriority right after CreateThread lowers the thread on Linux ... ea76cc841d

Assisted-by: Claude

posix: SetThreadPriority waits for a new thread's id instead of dropping the lowering ... 7fb4e2c171

Assisted-by: Claude

mooki added the

gpu/igpu

kind

bug

platform/linux

platform/steam-deck

priority

high

labels 2026-11-14 17:12:17 +00:00

dukenheimer referenced this pull request 2026-11-14 19:44:16 +00:00

perf(vk): the BC3 scratch has the layers a run uses, 20 MB instead of 160 #384

dukenheimer referenced this pull request 2026-11-14 19:44:17 +00:00

fix(vk): retain guest pages during import handoff and retirement #468

dukenheimer referenced this pull request 2026-11-14 19:44:17 +00:00

fix(vi): pace at 240 while a movie plays, so its player stops losing pictures #488

dukenheimer commented 2026-11-14 19:44:18 +00:00

Contributor

• Copy link
• Copy Markdown

Test request T-YHUH: pass

Hardware: Steam Deck OLED (AMD Custom APU 0932, RADV VANGOGH, 16 GB), Mesa 26.2.0-devel git-5c65d4fc31, SteamOS 3.9.5
(build 20261023.100), kernel 7.2.7-valve2. Built from this PR's head 7fb4e2c1, merged into a Deck user build (details below). The
comparison is the same build with this PR's merge reverted, not plain main.

What I checked

• The game's threads, ps -L -o ni,comm, every 30 s (7 to 9 samples a run).
• Real fps (the game's own frames) and frame times on the same save and the same moving Kokiri route.
• Runs with the PR were runs 1 and 8 of the series below; runs without it were 2 and 7.

Result

	OptimizeChange thread	real fps	shown fps (FG 3x)	p50 / p95 / p99 ms	GPU ms a frame (window median)
with this PR	10 OptimizeChangeB in every sample	13.1, 12.8	36.6, 36.0	16.7 / 73.4 / 155.7; 16.8 / 73.6 / 146.7	53.0, 53.1
without it	10 OptimizeChangeB in every sample	13.0, 13.5	36.3, 37.3	16.7 / 78.3 / 142.9; 16.7 / 79.1 / 159.3	53.7, 52.7

The thread was at nice 10 without this PR too. In both starts without the PR the new thread already had its id when
SetThreadPriority ran, so the lowering that this PR keeps from being lost was not lost on main's code either. Both arms lowered the
same other threads: 5 at nice 19 (hooksho:disk$0-$3) and 2 at nice 5 (mkw_vk); 102 stayed at 0.

fps. The medians are 12.95 with the PR and 13.25 without, inside the run-to-run spread (12.8 to 13.5 over all 8 runs of the
series). The priorities were the same in both arms, so this PR can't account for the difference. The p95 gap follows the run order:
by position in the series p95 was 73.4, 78.3, 79.4, 95.2, 100.7, 99.7, 79.1, 73.6 ms, rising toward the middle whatever ran there.

Two starts are few for a race. All this shows is that the lowering wasn't lost in 2 of 2 starts without the PR on this Deck at these
settings; with the PR it no longer depends on that.

Setup

• Deck: Steam Deck OLED: AMD Custom APU 0932 (RADV VANGOGH), 16 GB; SteamOS 3.9.5 build 20261023.100, kernel 7.2.7-valve2,
  Mesa 26.2.0-devel git-5c65d4fc31. Stock clocks. Game Mode, docked: the game gets a 1280x720 surface.
• Build: a Deck user build: main 543846eb + #227 0fc2e8c9 (with #225) + #223 52a61f40 + #232 3ccb48a8 + #303 995aab15, with
  #384 a9b0c880, #468 e5889e76, #488 abf2227f and #496 7fb4e2c1 merged on top. All four merged clean. Linux suite: 544 passed,
  main's 5 known failures. Built with x86-64-v3 and the release play profile, LLVM 23.1.5 (glibc 2.35).
• Without this PR: the same tree with this PR's merge reverted (git revert -m 1), built the same way. Only that file is swapped
  in one warm test folder: the host longshot for #496, longshot_vk.so for #384 and #468.
• Settings (the Deck owner's own): handheld profile (window crop 1536x864), output 1280x800, Render resolution 100%, the game's own
  upscaler, frame generation 3x, frame rate cap 60, vsync on. RX_VK_READBACK_EARLY=1 (#303) and HOS_VIDEO_LOG=1.
• Scene: Continue from a Kokiri Forest save, then a scripted moving route. 80 s are measured; caches are warm.
• Order: all four PRs (F), -#496, -#384, -#468, -#468, -#384, -#496, F: 2 runs each, mirrored about the middle.
  In runs 2 (-#496) and 4 (-#468) the scripted route went into a house after its start, so most of those two windows is an interior.

Test request T-YHUH: pass Hardware: Steam Deck OLED (AMD Custom APU 0932, RADV VANGOGH, 16 GB), Mesa 26.2.0-devel git-5c65d4fc31, SteamOS 3.9.5 (build 20261023.100), kernel 7.2.7-valve2. Built from this PR's head 7fb4e2c1, merged into a Deck user build (details below). The comparison is the same build with this PR's merge reverted, not plain main. **What I checked** - The game's threads, `ps -L -o ni,comm`, every 30 s (7 to 9 samples a run). - Real fps (the game's own frames) and frame times on the same save and the same moving Kokiri route. - Runs with the PR were runs 1 and 8 of the series below; runs without it were 2 and 7. **Result** | | `OptimizeChange` thread | real fps | shown fps (FG 3x) | p50 / p95 / p99 ms | GPU ms a frame (window median) | |---|---|---|---|---|---| | with this PR | `10 OptimizeChangeB` in every sample | 13.1, 12.8 | 36.6, 36.0 | 16.7 / 73.4 / 155.7; 16.8 / 73.6 / 146.7 | 53.0, 53.1 | | without it | `10 OptimizeChangeB` in every sample | 13.0, 13.5 | 36.3, 37.3 | 16.7 / 78.3 / 142.9; 16.7 / 79.1 / 159.3 | 53.7, 52.7 | **The thread was at nice 10 without this PR too.** In both starts without the PR the new thread already had its id when `SetThreadPriority` ran, so the lowering that this PR keeps from being lost was not lost on main's code either. Both arms lowered the same other threads: 5 at nice 19 (`hooksho:disk$0`-`$3`) and 2 at nice 5 (`mkw_vk`); 102 stayed at 0. **fps.** The medians are 12.95 with the PR and 13.25 without, inside the run-to-run spread (12.8 to 13.5 over all 8 runs of the series). The priorities were the same in both arms, so this PR can't account for the difference. The p95 gap follows the run order: by position in the series p95 was 73.4, 78.3, 79.4, 95.2, 100.7, 99.7, 79.1, 73.6 ms, rising toward the middle whatever ran there. Two starts are few for a race. All this shows is that the lowering wasn't lost in 2 of 2 starts without the PR on this Deck at these settings; with the PR it no longer depends on that. **Setup** - **Deck:** Steam Deck OLED: AMD Custom APU 0932 (RADV VANGOGH), 16 GB; SteamOS 3.9.5 build 20261023.100, kernel 7.2.7-valve2, Mesa 26.2.0-devel git-5c65d4fc31. Stock clocks. Game Mode, docked: the game gets a 1280x720 surface. - **Build:** a Deck user build: main 543846eb + #227 0fc2e8c9 (with #225) + #223 52a61f40 + #232 3ccb48a8 + #303 995aab15, with #384 a9b0c880, #468 e5889e76, #488 abf2227f and #496 7fb4e2c1 merged on top. All four merged clean. Linux suite: 544 passed, main's 5 known failures. Built with x86-64-v3 and the release play profile, LLVM 23.1.5 (glibc 2.35). - **Without this PR:** the same tree with this PR's merge reverted (`git revert -m 1`), built the same way. Only that file is swapped in one warm test folder: the host `longshot` for #496, `longshot_vk.so` for #384 and #468. - **Settings (the Deck owner's own):** handheld profile (window crop 1536x864), output 1280x800, Render resolution 100%, the game's own upscaler, frame generation 3x, frame rate cap 60, vsync on. `RX_VK_READBACK_EARLY=1` (#303) and `HOS_VIDEO_LOG=1`. - **Scene:** Continue from a Kokiri Forest save, then a scripted moving route. 80 s are measured; caches are warm. - **Order:** all four PRs (F), -#496, -#384, -#468, -#468, -#384, -#496, F: 2 runs each, mirrored about the middle. In runs 2 (-#496) and 4 (-#468) the scripted route went into a house after its start, so most of those two windows is an interior.

zeldaootr force-pushed posix-thread-priority-before-start from 7fb4e2c171 to 27113be72e 2026-11-14 20:33:38 +00:00 Compare

zeldaootr commented 2026-11-14 20:33:39 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Rebased onto main 7ff5256e, and dukenheimer's Steam Deck result (T-YHUH: pass) is in the description: the thread ran at nice 10 with and without this PR in 2 of 2 starts there, so on that Deck it changed nothing measured; it removes a race the game-free test loses 19 or 20 times of 20. Thank you for the run.

Rebased onto main 7ff5256e, and dukenheimer's Steam Deck result (T-YHUH: pass) is in the description: the thread ran at nice 10 with and without this PR in 2 of 2 starts there, so on that Deck it changed nothing measured; it removes a race the game-free test loses 19 or 20 times of 20. Thank you for the run.

zeldaootr changed title from WIP: fix(host): a thread lowered right after it is created runs lowered on Linux to fix(host): a thread lowered right after it is created runs lowered on Linux 2026-11-14 20:33:40 +00:00

HuzZz referenced this pull request 2026-11-14 22:59:21 +00:00

Sun shadows on Link flicker/break dependant on camera view #601

zeldaootr referenced this pull request 2026-11-15 16:41:36 +00:00

fix(vk): retain guest pages during import handoff and retirement #468

zeldaootr commented 2026-11-15 16:41:45 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Rebased onto main aa95d35f with no conflict (the same two changes, git patch-id; host/posix/win32_posix.c is untouched by main since 7ff5256e) and the description moved to the current template; the stale "not measured in the game yet" line is gone, since dukenheimer's T-YHUH Deck run is in.
The game-free test was run again on the new base (20 of 20 kept the normal priority at the test-only commit, 20 of 20 at nice 10 at the tip, two rounds, g++ and clang); the Deck numbers still hold: since that build (main 543846eb) main changed the changed file not at all and host/hos_thread.c only in which core is kept for the replay (#522), not in the priority path.

Rebased onto `main` aa95d35f with no conflict (the same two changes, `git patch-id`; `host/posix/win32_posix.c` is untouched by `main` since 7ff5256e) and the description moved to the current template; the stale "not measured in the game yet" line is gone, since dukenheimer's T-YHUH Deck run is in. The game-free test was run again on the new base (20 of 20 kept the normal priority at the test-only commit, 20 of 20 at nice 10 at the tip, two rounds, g++ and clang); the Deck numbers still hold: since that build (main 543846eb) `main` changed the changed file not at all and `host/hos_thread.c` only in which core is kept for the replay (#522), not in the priority path.

zeldaootr force-pushed posix-thread-priority-before-start from 27113be72e to 6218c00b8a 2026-11-15 16:43:29 +00:00 Compare

Some checks are pending

Hide checks

CI / Conventional Commit title (pull_request) Blocked by required conditions

Details

CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Blocked by required conditions

Details

CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Blocked by required conditions

Details

CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Blocked by required conditions

Details

CI / Workflow lint (actionlint) (pull_request) Blocked by required conditions

Details

Guide screenshots / Guide images and local UI source review (pull_request) Blocked by required conditions

Details

Third-party parts / As their notes say (pull_request) Blocked by required conditions

Details

Third-party parts / The same as upstream (pull_request) Blocked by required conditions

Details

Website / Website on Cloudflare (pull_request) Blocked by required conditions

Details

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

Details

This pull request doesn't have enough approvals yet. 0 of 1 approvals granted.

Some workflows are waiting to be reviewed.

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

You are not authorized to merge this pull request.

View command line instructions

Checkout

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

git fetch -u 'posix-thread-priority-before-start:zeldaootr-posix-thread-priority-before-start'

git switch 'zeldaootr-posix-thread-priority-before-start'

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

  

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 @ 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/upscaling

beanstalk: approved @ 1697603

beanstalk: approved @ 2c5a62e

beanstalk: approved @ 4fd82b7

beanstalk: approved @ 64d6d09

beanstalk: approved @ 6f91fae

beanstalk: approved @ 70a78f9

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

2 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!496

No description provided.