fix(vcores): honour mask 0 and keep the guest's core cache correct #327

Open

DuckNintendo wants to merge 3 commits from DuckNintendo/Longshot:fix/vcore-mask0-cache into main

pull from: DuckNintendo/Longshot:fix/vcore-mask0-cache

merge into: MagicBeanDev:main

MagicBeanDev:main

Conversation 6 Commits 3 Files changed 3 +270 -6

DuckNintendo commented 2026-11-14 00:33:41 +00:00

First-time contributor

• Copy link
• Copy Markdown

Why

Mask 0 is the guest's "no affinity" value, but the host treats it as one core: a mask-0
thread cannot use another core even when the core it started on is busy. This change makes
mask 0 mean every host core, keeps the guest's cached core as the first choice, and rewrites
the guest's TLS core cell whenever the thread is placed elsewhere.

What changed

• host/hos_thread.c: hos_thread_affinity() stores mask 0 instead of ignoring it. vc_allowed() treats mask 0 as "every host core" rather than pinning to one.
• host/hos_thread.c: vc_pref_core() and vc_free_for() prefer the core in the guest's TLS cell, then the thread's last core, then its ideal/lowest core, and request a remask when the cached core is busy.
• host/hos_thread.c: vc_note_mask_change() and vc_yield() force a move when a new mask excludes the held core, even with no waiter.
• host/hos_thread.c: vc_take()/vc_sync_tls() write the guest's core cell on every take: core + 1 for a 0/single-bit mask, 0 for a multi-bit mask, and on a same-core mask change. The core slot is discovered from the guest's own AllocateTlsSlot call, not assumed.
• tests/test_vcore_mask0.py: new host-only fixture for the above.
• tests/test_vcore_escape.py: stubs for the new core-cache helpers.

Flags and settings

None. No switch, menu row or ini key is added or changed.

Measurements

main: 16047f55
this PR: fix/vcore-mask0-cache @ 86b51d71

Hardware: x86-64 host, Vulkan. These are CPU scheduling counters; no GPU path is involved.
Scene: HyruleField_Child at a saved spot, default settings, 1280x720, 60 fps cap.
Method: main, PR, main, PR; 10 s warm-up and 60 s sampling per run; the same save, settings
and movement pattern. FPS and draws are sampled once a second; the scheduling counters are
cumulative from process start and identical for both. The raw values of the two runs are in
the row labels.
How to reproduce: load the saved spot and hold a run for 60 s. The counter instrumentation
is in the closed testing-only PR #412 (do not merge), which contains this PR's head plus
the counters: #412
It is not part of this PR.

	main @ 16047f55	this PR @ 86b51d71
FPS median (runs 59.9, 59.1 / 59.2, 60.1)	59.5	59.65
draws median (runs 2148, 2103 / 2053, 1989)	2125.5	2021
takes median	2,935,053	2,958,206
mask-0 takes median (runs 176, 164 / 160, 227)	170	193.5
mask-0 taken off the cached core (runs 2, 2 / 104, 154)	2	129
mask-0 cell wrong after the take (runs 2, 2 / 0, 0)	2	0

Rebase: the branch was rebased through 0caf0618 onto 5e072fc8 (head 96107450). The
new commits are Vulkan/actor-motion changes; they do not touch the mask-0/TLS paths
measured here (vc_allowed, vc_pref_core, vc_take, vc_sync_tls). The counters still
describe this code, and the scene remains cap-bound.

Main pins a mask-0 thread to one core, so it takes a core other than the guest's cached
core only twice in 60 s and the cell after the take is wrong twice. This PR uses the free
cores: 129 such takes in the median run, and the cell after the take is never wrong because
vc_take() rewrites it. FPS is cap-bound at 60 in both and the draw counts are comparable:
this is not a frame-rate win, it is the cache maintenance that lets mask 0 use the other
cores.

Testing

Tested: python -I -B tests/run_all.py --jobs 8 on the rebased head: 497 passed,
2 failed, 63 skipped. The failures are tests/test_module_ids.py and
tests/test_pad_layout.py; both also fail on untouched 5e072fc8. The new tests/test_vcore_mask0.py and the updated
tests/test_vcore_escape.py pass; the touched host files compile with the build's flags.
Four Hyrule Field runs (main, PR, main, PR) at the saved spot; no crash; every run stayed
on HyruleField_Child, and the counters are above. The no-save title-idle (100 s) → New
Game → intro route was also run twice per build with the same counters: both reached
Kokiri Forest; main's mask-0 off-cache takes were 1 and 1, with 1 wrong cell after the
take each; this PR's were 83 and 97, with 0 wrong cells each. The same route was run
twice more per build without the control bridge (HOS_INPUT_SCRIPT); all four runs
reached Kokiri Forest as well.

Not tested: no longer route than the saved spot; no scene where the cached core is
heavily contended; no uncapped frame rate or higher resolution, so whether the extra
mask-0 placements help is not shown. The real nn::os::Mutex + second-thread SetMask
case belongs to the separate lock-held change, not this PR.

Needs other testers:

• CPU-limited systems (Steam Deck, 4-core x86, low-TDP laptops): compare main and this PR
  in Hyrule Field, Kokiri Forest and the Market for 5-10 minutes, including transitions and
  the pause menu; look for hangs, crashes or wrong per-core data and compare the frame
  rate, expecting no hang or crash and no worse frame rate (T-5HRS). The request is open
  but needs the testing wanted label before testers can claim it.

Screenshots

Nothing on screen.

Risk and rollback

Mask-0 threads move between cores more than before (129 off-cache takes in the median run
against 2). If the cell sync were wrong, the guest would use per-core data from the wrong
core. The fixture covers the cell values and the scene run never left a wrong cell after a
take. Reverting the commit restores the pinning; there is no flag.

Reviewer notes

Start with vc_pref_core(), vc_free_for(), vc_take()/vc_sync_tls() and
vc_note_mask_change() in host/hos_thread.c; the fixture names each case. The lock-held
deferral is a separate follow-up and is not part of this PR.

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).
• 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.
• Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported.
• 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.

## Why Mask 0 is the guest's "no affinity" value, but the host treats it as one core: a mask-0 thread cannot use another core even when the core it started on is busy. This change makes mask 0 mean every host core, keeps the guest's cached core as the first choice, and rewrites the guest's TLS core cell whenever the thread is placed elsewhere. ## What changed - `host/hos_thread.c`: `hos_thread_affinity()` stores mask 0 instead of ignoring it. `vc_allowed()` treats mask 0 as "every host core" rather than pinning to one. - `host/hos_thread.c`: `vc_pref_core()` and `vc_free_for()` prefer the core in the guest's TLS cell, then the thread's last core, then its ideal/lowest core, and request a remask when the cached core is busy. - `host/hos_thread.c`: `vc_note_mask_change()` and `vc_yield()` force a move when a new mask excludes the held core, even with no waiter. - `host/hos_thread.c`: `vc_take()`/`vc_sync_tls()` write the guest's core cell on every take: `core + 1` for a 0/single-bit mask, 0 for a multi-bit mask, and on a same-core mask change. The core slot is discovered from the guest's own `AllocateTlsSlot` call, not assumed. - `tests/test_vcore_mask0.py`: new host-only fixture for the above. - `tests/test_vcore_escape.py`: stubs for the new core-cache helpers. ## Flags and settings None. No switch, menu row or ini key is added or changed. ## Measurements main: 16047f55 this PR: fix/vcore-mask0-cache @ 86b51d71 Hardware: x86-64 host, Vulkan. These are CPU scheduling counters; no GPU path is involved. Scene: `HyruleField_Child` at a saved spot, default settings, 1280x720, 60 fps cap. Method: main, PR, main, PR; 10 s warm-up and 60 s sampling per run; the same save, settings and movement pattern. FPS and draws are sampled once a second; the scheduling counters are cumulative from process start and identical for both. The raw values of the two runs are in the row labels. How to reproduce: load the saved spot and hold a run for 60 s. The counter instrumentation is in the closed testing-only PR #412 (do not merge), which contains this PR's head plus the counters: https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/412 It is not part of this PR. | | main @ 16047f55 | this PR @ 86b51d71 | |---|---|---| | FPS median (runs 59.9, 59.1 / 59.2, 60.1) | 59.5 | 59.65 | | draws median (runs 2148, 2103 / 2053, 1989) | 2125.5 | 2021 | | takes median | 2,935,053 | 2,958,206 | | mask-0 takes median (runs 176, 164 / 160, 227) | 170 | 193.5 | | mask-0 taken off the cached core (runs 2, 2 / 104, 154) | 2 | 129 | | mask-0 cell wrong after the take (runs 2, 2 / 0, 0) | 2 | 0 | Rebase: the branch was rebased through `0caf0618` onto `5e072fc8` (head `96107450`). The new commits are Vulkan/actor-motion changes; they do not touch the mask-0/TLS paths measured here (`vc_allowed`, `vc_pref_core`, `vc_take`, `vc_sync_tls`). The counters still describe this code, and the scene remains cap-bound. Main pins a mask-0 thread to one core, so it takes a core other than the guest's cached core only twice in 60 s and the cell after the take is wrong twice. This PR uses the free cores: 129 such takes in the median run, and the cell after the take is never wrong because `vc_take()` rewrites it. FPS is cap-bound at 60 in both and the draw counts are comparable: this is not a frame-rate win, it is the cache maintenance that lets mask 0 use the other cores. ## Testing **Tested:** `python -I -B tests/run_all.py --jobs 8` on the rebased head: 497 passed, 2 failed, 63 skipped. The failures are `tests/test_module_ids.py` and `tests/test_pad_layout.py`; both also fail on untouched `5e072fc8`. The new `tests/test_vcore_mask0.py` and the updated `tests/test_vcore_escape.py` pass; the touched host files compile with the build's flags. Four Hyrule Field runs (main, PR, main, PR) at the saved spot; no crash; every run stayed on `HyruleField_Child`, and the counters are above. The no-save title-idle (100 s) → New Game → intro route was also run twice per build with the same counters: both reached Kokiri Forest; main's mask-0 off-cache takes were 1 and 1, with 1 wrong cell after the take each; this PR's were 83 and 97, with 0 wrong cells each. The same route was run twice more per build without the control bridge (`HOS_INPUT_SCRIPT`); all four runs reached Kokiri Forest as well. **Not tested:** no longer route than the saved spot; no scene where the cached core is heavily contended; no uncapped frame rate or higher resolution, so whether the extra mask-0 placements help is not shown. The real `nn::os::Mutex` + second-thread `SetMask` case belongs to the separate lock-held change, not this PR. **Needs other testers:** - CPU-limited systems (Steam Deck, 4-core x86, low-TDP laptops): compare main and this PR in Hyrule Field, Kokiri Forest and the Market for 5-10 minutes, including transitions and the pause menu; look for hangs, crashes or wrong per-core data and compare the frame rate, expecting no hang or crash and no worse frame rate (T-5HRS). The request is open but needs the `testing wanted` label before testers can claim it. ## Screenshots Nothing on screen. ## Risk and rollback Mask-0 threads move between cores more than before (129 off-cache takes in the median run against 2). If the cell sync were wrong, the guest would use per-core data from the wrong core. The fixture covers the cell values and the scene run never left a wrong cell after a take. Reverting the commit restores the pinning; there is no flag. ## Reviewer notes Start with `vc_pref_core()`, `vc_free_for()`, `vc_take()`/`vc_sync_tls()` and `vc_note_mask_change()` in `host/hos_thread.c`; the fixture names each case. The lock-held deferral is a separate follow-up and is not part of this PR. ## Issues None. ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main`. - [x] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). - [x] Tested in the game, or what wasn't is named under Testing. - [x] Testing filled in: what was tested, what wasn't, and what needs other testers. - [x] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. - [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.

DuckNintendo force-pushed fix/vcore-mask0-cache from e29caaa75e to 86b51d7174 2026-11-14 00:37:00 +00:00 Compare

DuckNintendo commented 2026-11-14 01:13:24 +00:00

Author

First-time contributor

• Copy link
• Copy Markdown

Hyrule Field measurement added to the description. Two interleaved runs each, 10 s warm-up and 60 s sampling at the same saved spot:

• main: 2 mask-0 takes off the cached core, 2 wrong cells after the take.
• this PR: 129 off-cache takes (median), 0 wrong cells after the take.
• FPS median 59.5 on main and 59.65 here; the scene is cap-bound at 60.

So this is the cache maintenance that lets mask 0 use the other cores, not a frame-rate win. The earlier 90 s/two-core counts were from this PR's own policy, not a main-vs-PR bug count; the description now uses the scene comparison.

Hyrule Field measurement added to the description. Two interleaved runs each, 10 s warm-up and 60 s sampling at the same saved spot: - main: 2 mask-0 takes off the cached core, 2 wrong cells after the take. - this PR: 129 off-cache takes (median), 0 wrong cells after the take. - FPS median 59.5 on main and 59.65 here; the scene is cap-bound at 60. So this is the cache maintenance that lets mask 0 use the other cores, not a frame-rate win. The earlier 90 s/two-core counts were from this PR's own policy, not a main-vs-PR bug count; the description now uses the scene comparison.

mooki added the

kind

bug

label 2026-11-14 01:46:14 +00:00

mooki added the

priority

high

label 2026-11-14 04:18:37 +00:00

DuckNintendo force-pushed fix/vcore-mask0-cache from 86b51d7174 to f55b29d6ec 2026-11-14 10:53:31 +00:00 Compare

DuckNintendo commented 2026-11-14 10:53:39 +00:00

Author

First-time contributor

• Copy link
• Copy Markdown

Rebased onto current main 0caf0618; head is f55b29d6. The suite on the rebased head is 497 passed / 2 failed / 63 skipped; both failures (test_module_ids.py, test_pad_layout.py) also fail on untouched 0caf0618. The Hyrule Field table was taken at 16047f55/86b51d71; the rebase changes the hos_thread_of current-thread fast path and condition-variable signaling, not the mask-0/TLS paths measured.

Rebased onto current `main` `0caf0618`; head is `f55b29d6`. The suite on the rebased head is 497 passed / 2 failed / 63 skipped; both failures (`test_module_ids.py`, `test_pad_layout.py`) also fail on untouched `0caf0618`. The Hyrule Field table was taken at `16047f55`/`86b51d71`; the rebase changes the `hos_thread_of` current-thread fast path and condition-variable signaling, not the mask-0/TLS paths measured.

DuckNintendo commented 2026-11-14 10:55:39 +00:00

Author

First-time contributor

• Copy link
• Copy Markdown

Counters are in the closed testing-only PR #412 (do not merge): #412

It is #327's head plus the PERF counters and the report call. Closed so it cannot be merged; the diff stays available on the PR page.

Counters are in the closed testing-only PR #412 (do not merge): https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/412 It is #327's head plus the PERF counters and the report call. Closed so it cannot be merged; the diff stays available on the PR page.

DuckNintendo changed title from WIP: fix(vcores): honour mask 0 and keep the guest's core cache correct to fix(vcores): honour mask 0 and keep the guest's core cache correct 2026-11-14 10:55:39 +00:00

DuckNintendo referenced this pull request 2026-11-14 10:58:43 +00:00

WIP: test(vcores): counters for the #327 measurement (do not merge) #412

DuckNintendo commented 2026-11-14 11:21:11 +00:00

Author

First-time contributor

• Copy link
• Copy Markdown

Additional no-save route with the counters: title idle 100 s, then New Game and the intro video, two runs per build.

• main: mask-0 takes 66/100, 1/1 off the cached core, 1/1 wrong cell after the take.
• this PR: 132/168 takes, 83/97 off-cache, 0/0 wrong cells after the take.
• Both reached Kokiri Forest; no crash in 2/2 each.

Same pattern as Hyrule Field: main pins the thread, so its cell stays aligned; the PR uses the free cores and rewrites the cell at every take.

Additional no-save route with the counters: title idle 100 s, then New Game and the intro video, two runs per build. - main: mask-0 takes 66/100, 1/1 off the cached core, 1/1 wrong cell after the take. - this PR: 132/168 takes, 83/97 off-cache, 0/0 wrong cells after the take. - Both reached Kokiri Forest; no crash in 2/2 each. Same pattern as Hyrule Field: main pins the thread, so its cell stays aligned; the PR uses the free cores and rewrites the cell at every take.

DuckNintendo commented 2026-11-14 14:31:55 +00:00

Author

First-time contributor

• Copy link
• Copy Markdown

Rebased through 0caf0618 onto current main 5e072fc8; head is 96107450. Suite on the rebased head: 497 passed / 2 failed / 63 skipped; both failures (test_module_ids.py, test_pad_layout.py) also fail on untouched 5e072fc8. The new main commits are Vulkan/actor-motion changes, not the mask-0/TLS paths.

Rebased through `0caf0618` onto current `main` `5e072fc8`; head is `96107450`. Suite on the rebased head: 497 passed / 2 failed / 63 skipped; both failures (`test_module_ids.py`, `test_pad_layout.py`) also fail on untouched `5e072fc8`. The new main commits are Vulkan/actor-motion changes, not the mask-0/TLS paths.

DuckNintendo force-pushed fix/vcore-mask0-cache from f55b29d6ec to 96107450ac 2026-11-14 14:31:56 +00:00 Compare

DuckNintendo commented 2026-11-14 14:42:42 +00:00

Author

First-time contributor

• Copy link
• Copy Markdown

Test request T-5HRS is open for CPU-limited systems: Steam Deck, 4-core x86 or a low-TDP laptop; Hyrule Field, Kokiri Forest and the Market, comparing main with this PR and looking for hangs, crashes, wrong per-core data and frame-rate regressions.

The request cannot be claimed yet: #327 is not from a collaborator and has no testing wanted label. Could a maintainer add that label? The token I have gets 403 when it tries.

Test request **T-5HRS** is open for CPU-limited systems: Steam Deck, 4-core x86 or a low-TDP laptop; Hyrule Field, Kokiri Forest and the Market, comparing main with this PR and looking for hangs, crashes, wrong per-core data and frame-rate regressions. The request cannot be claimed yet: #327 is not from a collaborator and has no `testing wanted` label. Could a maintainer add that label? The token I have gets 403 when it tries.

mooki added the

platform/linux

platform/windows

labels 2026-11-14 18:23:04 +00:00

mooki referenced this pull request 2026-11-14 22:01:56 +00:00

fix(vcores): a thread starved of its core gets it after 1 s, not an escape after 2 s (#262) #594

mooki referenced this pull request 2026-11-14 22:02:06 +00:00

Game: while a save loads, worker threads sometimes wait the full 2 s for a virtual core and then run without one (main too) #262

DuckNintendo referenced this pull request 2026-11-15 00:11:24 +00:00

fix(vcores): a thread starved of its core gets it after 1 s, not an escape after 2 s (#262) #594

SocialWare referenced this pull request 2026-11-15 13:27:34 +00:00

Game: Crash in Hyrule field after opening and closing map #809

malon referenced this pull request 2026-11-15 15:11:03 +00:00

Game: Keeps on crashing in death mountain #817

MaikelJSQ referenced this pull request 2026-11-15 18:05:02 +00:00

Game: Longshot closed unexpectedly while you were playing #859

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

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 5s

Details

Website / Website on Cloudflare (pull_request_target) Has been skipped

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 'fix/vcore-mask0-cache:DuckNintendo-fix/vcore-mask0-cache'

git switch 'DuckNintendo-fix/vcore-mask0-cache'

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

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

No description provided.