MagicBeanDev/Longshot
MagicBeanDev/Longshot
Watch
75
95
Fork
You've already forked Longshot
 98
Code Issues 225 Pull requests 265 Projects Releases 9 Packages Wiki Activity Actions 880

fix(vk): free on the GPU's progress, not on a time or a frame count: read-back timeouts and the upscalers' frees #788

Open
mooki wants to merge 1 commit from mooki/Longshot:fix/async-safe-frees into main
pull from: mooki/Longshot:fix/async-safe-frees
merge into: MagicBeanDev:main
Conversation 0 Commits 1 Files changed 8 +271 -20
mooki commented 2026-11-15 11:59:12 +00:00
Member

Type: fix · Risk: low · Tested on: macOS 26.7, Apple M4 Max (game-free checks only, arm64 and x86_64) · Needs: Windows and Linux, any GPU

Why

When the GPU runs late, the renderer can free or reset things the GPU is still using. Two places go by a clock or a frame count instead of the GPU's progress:

  • After a texture write-back's read-back waits 5 s without finishing, the next read-back resets its command pool and fence and records into its command buffer again, while the GPU may still be running it.
  • With no window (HOS_HEADLESS), the upscalers' images are freed 4 frames after they were last used. Nothing in that mode waits for the GPU each frame, so the GPU can still be using them.

Either can end in a GPU fault or a lost device, on any GPU. Neither has been seen in a game; they were found by reading the source, and the new test shows each one on main's code. The issue tracker's titles (snapshot of 2026-11-14 20:01) have nothing that fits: #130 and #583 are device losses with other causes, #241 is the read-back's cost.

How to reproduce

Seen on: not seen in a game; shown on main's own functions by tests/test_async_safe_frees.py and tests/test_ui_texture_upload.py (case headless), on any OS
Settings and switches: for the read-back: any settings, a GPU stall of more than 5 s during a texture write-back (vk: a batch of N texture write-backs did not complete in time); for the frees: HOS_HEADLESS=1 with DLSS, FSR 3.1 or FSR 4 as the upscaler or RX_VK_REACTIVE=1, or RX_VK_SHOT_MENU=1
Steps: run python -I -B tests/test_async_safe_frees.py --headers <Vulkan-Headers/include> on main; in a game run, set RX_VK_VALIDATION=1 with the settings above and play while the GPU is busy (an area load)
Expected: nothing reset, begun or destroyed while a GPU command may still use it
Actual: the test reports a pool and a fence reset, and a command buffer begun, under a read-back that has not finished, and each of the three free lists freeing before the GPU passed the work that used it. The validation layer would name it (for example VUID-vkResetCommandPool-commandPool-00040, VUID-vkDestroyImage-image-01000) when the GPU is that far behind

What changed

The read-back waits for a submit whose 5 s wait ran out before its pool or fence is reset. The free lists counted in frames also wait for the timeline value that followed the work, as vk_fsr3.cpp (drop_image, free_dead) already does. Nothing is freed earlier than before; it is only freed later where the GPU had not finished.

  • read-backs, gpu/vk/vk_texture.cpp:
    • readback_begin (main :3077) reset rb_pool, and readback_submit_wait (:3111) reset rb_fence, with no wait after the 5 s wait (:3117) had given up. Vulkan forbids both resets while the command buffer or the submit is pending, and drivers reuse a reset pool's command memory.
    • Now rb_pending stays set from the submit until its fence is seen signalled, and readback_settle() waits for it without a limit before either reset.
    • flush_textures's timeout branch (:3337) already kept the batch's staging buffers until the next submission (:3348). The images the copies read were left free: a texture's death waits only for its last_value on the timeline (:4671, :4684), and the read-back's own submit is not on it. Each copied texture's last_value is now raised to that same submission.
  • frees counted in frames, gpu/vk/vk_reactive.cpp, gpu/vk/vk_temporal.cpp, gpu/vk/vk_fsr3_inputs.cpp:
    • later and free_dead (main vk_reactive.cpp:76, :81; vk_temporal.cpp:291, :296; vk_fsr3_inputs.cpp:98, :103) freed an image, view, buffer or released feature 4 frames on. This includes DLSS's and FSR 4's, through temporal_later (vk_temporal.cpp:821).
    • With no window, do_present returns before present_image (gpu/vk/vk_replay.cpp:4499), so nothing waits for the present ring's fences. Only the 48-slot recording ring (vk_replay.cpp:176) limits how far behind the GPU is, and that is many frames when a frame has few recordings.
    • Each entry now also keeps vk_retirement_value() from when it was let go. It is freed once vk_timeline_completed() has passed that value, and never on a value of 0.
  • the overlays' dead list, gpu/vk/vk_imgui.cpp:
    • reap (main :197, :200) frees 4 counts on. With no window the overlays are drawn into the replay's recordings (RX_VK_SHOT_MENU), and idle() (:477) counts frames without waiting for the GPU.
    • With no window an entry now waits for the timeline value too. In a window it is as before (the present ring's fences).
  • Left as they are: TAAU's replaced histories (vk_draw.cpp, 120 frames). With no window every frame records its offscreen copy, so 120 frames are more recordings than the ring holds.

Measurements

Verdict: nothing to measure. A normal run does the same work at the same time; only a GPU that runs late changes when something is freed.

Flags and settings

None

Testing

Tested: game-free, on macOS 26.7, Apple M4 Max, arm64 and x86_64 (Rosetta):

  • tests/test_async_safe_frees.py (new) and tests/test_ui_texture_upload.py (case headless added) fail on main aa95d35f and pass on this PR, on both architectures.
  • Whole-file compiles of the six renderer files touched or referenced (vk_texture.cpp, vk_reactive.cpp, vk_temporal.cpp, vk_fsr3_inputs.cpp, vk_imgui.cpp, vk_replay.cpp) with nx2/build.py's macOS commands, on both architectures: every compile exits 0 with no warnings, as on main.
  • An object check finds the only new references are vk_retirement_value and vk_timeline_completed, both defined in vk_replay.o.
  • python -I -B tests/run_all.py on this Mac, where main's runner takes macOS for Linux: 544 passed, 33 failed, 17 skipped. Main aa95d35f gives 543 passed, 33 failed, 17 skipped, and by name every result is the same apart from the new test (pass). The 33 fail the same way on main on this Mac: test_appimage_package_retry, test_appimage_player_build, test_collect_wide, test_control, test_cpm_discovery, test_crash_dialog, test_crash_record, test_env_on, test_game_layout, test_lift_cleanup_error, test_linux_preflight, test_longshot_ctl, test_low_memory_notice, test_make_game_cache, test_mem_gate, test_mem_gate_children, test_mirror_trim, test_oot_state_tap, test_options_budget_once, test_options_path, test_pcache_header_read, test_pipeline_cache_file, test_pipeline_cache_save, test_pipeline_play_cache, test_pipeline_tour, test_prof_symbols, test_program_cache_cleanup, test_program_cache_one_variant, test_readback_late, test_report_run, test_split_giants, test_vk_pgo, test_walk_key.

Not tested: in the game, on any platform (neither hazard can be produced on demand: it needs a GPU stall over 5 s, or the GPU more than 4 frames behind with no window). Not built on Windows (llvm-mingw) or Linux. The code has no platform branch, so it runs the same on both.

Must be tested:

  • Windows and Linux, any GPU, with the Khronos validation layer installed: build this PR (head 90f6c3e3) and main aa95d35f the same way and run python -I -B tests/run_all.py. Then start each with HOS_HEADLESS=1 RX_VK_FSR=1 RX_VK_REACTIVE=1 RX_VK_VALIDATION=1 (no window, FSR 3.1, the reactive mask) and play to the title and into the field. Expect every check to pass, and no validation error on this PR that main does not also show. A read-back that runs out of its 5 s wait cannot be made on demand (by hand: test request T-NTFW)

Risks

What could break: a read-back after a GPU stall now waits for the stall to end instead of going on. A real hang still ends at the GPU hang watch (RX_VK_GPU_HANG_SEC, 30 s). The upscalers' images and the headless overlays are kept until the GPU has passed them, at most a few frames longer than before.

Turning it off: revert the commit

Compatibility: Nothing changes

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. (Test request T-NTFW.)
  • Rebased on current main (main aa95d35f, head 90f6c3e3).
  • 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.
  • A game-free test added for the fix, failing on main and passing here.
  • A check under tests/ that reads changed source updated in this PR, not weakened.
**Type:** fix · **Risk:** low · **Tested on:** macOS 26.7, Apple M4 Max (game-free checks only, arm64 and x86_64) · **Needs:** Windows and Linux, any GPU ## Why When the GPU runs late, the renderer can free or reset things the GPU is still using. Two places go by a clock or a frame count instead of the GPU's progress: - After a texture write-back's read-back waits 5 s without finishing, the next read-back resets its command pool and fence and records into its command buffer again, while the GPU may still be running it. - With no window (`HOS_HEADLESS`), the upscalers' images are freed 4 frames after they were last used. Nothing in that mode waits for the GPU each frame, so the GPU can still be using them. Either can end in a GPU fault or a lost device, on any GPU. Neither has been seen in a game; they were found by reading the source, and the new test shows each one on main's code. The issue tracker's titles (snapshot of 2026-11-14 20:01) have nothing that fits: #130 and #583 are device losses with other causes, #241 is the read-back's cost. ## How to reproduce **Seen on:** not seen in a game; shown on main's own functions by `tests/test_async_safe_frees.py` and `tests/test_ui_texture_upload.py` (case `headless`), on any OS **Settings and switches:** for the read-back: any settings, a GPU stall of more than 5 s during a texture write-back (`vk: a batch of N texture write-backs did not complete in time`); for the frees: `HOS_HEADLESS=1` with DLSS, FSR 3.1 or FSR 4 as the upscaler or `RX_VK_REACTIVE=1`, or `RX_VK_SHOT_MENU=1` **Steps:** run `python -I -B tests/test_async_safe_frees.py --headers <Vulkan-Headers/include>` on main; in a game run, set `RX_VK_VALIDATION=1` with the settings above and play while the GPU is busy (an area load) **Expected:** nothing reset, begun or destroyed while a GPU command may still use it **Actual:** the test reports a pool and a fence reset, and a command buffer begun, under a read-back that has not finished, and each of the three free lists freeing before the GPU passed the work that used it. The validation layer would name it (for example `VUID-vkResetCommandPool-commandPool-00040`, `VUID-vkDestroyImage-image-01000`) when the GPU is that far behind ## What changed The read-back waits for a submit whose 5 s wait ran out before its pool or fence is reset. The free lists counted in frames also wait for the timeline value that followed the work, as `vk_fsr3.cpp` (`drop_image`, `free_dead`) already does. Nothing is freed earlier than before; it is only freed later where the GPU had not finished. - read-backs, `gpu/vk/vk_texture.cpp`: - `readback_begin` (main `:3077`) reset `rb_pool`, and `readback_submit_wait` (`:3111`) reset `rb_fence`, with no wait after the 5 s wait (`:3117`) had given up. Vulkan forbids both resets while the command buffer or the submit is pending, and drivers reuse a reset pool's command memory. - Now `rb_pending` stays set from the submit until its fence is seen signalled, and `readback_settle()` waits for it without a limit before either reset. - `flush_textures`'s timeout branch (`:3337`) already kept the batch's staging buffers until the next submission (`:3348`). The images the copies read were left free: a texture's death waits only for its `last_value` on the timeline (`:4671`, `:4684`), and the read-back's own submit is not on it. Each copied texture's `last_value` is now raised to that same submission. - frees counted in frames, `gpu/vk/vk_reactive.cpp`, `gpu/vk/vk_temporal.cpp`, `gpu/vk/vk_fsr3_inputs.cpp`: - `later` and `free_dead` (main `vk_reactive.cpp:76`, `:81`; `vk_temporal.cpp:291`, `:296`; `vk_fsr3_inputs.cpp:98`, `:103`) freed an image, view, buffer or released feature 4 frames on. This includes DLSS's and FSR 4's, through `temporal_later` (`vk_temporal.cpp:821`). - With no window, `do_present` returns before `present_image` (`gpu/vk/vk_replay.cpp:4499`), so nothing waits for the present ring's fences. Only the 48-slot recording ring (`vk_replay.cpp:176`) limits how far behind the GPU is, and that is many frames when a frame has few recordings. - Each entry now also keeps `vk_retirement_value()` from when it was let go. It is freed once `vk_timeline_completed()` has passed that value, and never on a value of 0. - the overlays' dead list, `gpu/vk/vk_imgui.cpp`: - `reap` (main `:197`, `:200`) frees 4 counts on. With no window the overlays are drawn into the replay's recordings (`RX_VK_SHOT_MENU`), and `idle()` (`:477`) counts frames without waiting for the GPU. - With no window an entry now waits for the timeline value too. In a window it is as before (the present ring's fences). - Left as they are: TAAU's replaced histories (`vk_draw.cpp`, 120 frames). With no window every frame records its offscreen copy, so 120 frames are more recordings than the ring holds. ## Measurements **Verdict:** nothing to measure. A normal run does the same work at the same time; only a GPU that runs late changes when something is freed. ### Flags and settings None ## Testing **Tested:** game-free, on macOS 26.7, Apple M4 Max, arm64 and x86_64 (Rosetta): - `tests/test_async_safe_frees.py` (new) and `tests/test_ui_texture_upload.py` (case `headless` added) fail on main `aa95d35f` and pass on this PR, on both architectures. - Whole-file compiles of the six renderer files touched or referenced (`vk_texture.cpp`, `vk_reactive.cpp`, `vk_temporal.cpp`, `vk_fsr3_inputs.cpp`, `vk_imgui.cpp`, `vk_replay.cpp`) with `nx2/build.py`'s macOS commands, on both architectures: every compile exits 0 with no warnings, as on main. - An object check finds the only new references are `vk_retirement_value` and `vk_timeline_completed`, both defined in `vk_replay.o`. - `python -I -B tests/run_all.py` on this Mac, where main's runner takes macOS for Linux: 544 passed, 33 failed, 17 skipped. Main `aa95d35f` gives 543 passed, 33 failed, 17 skipped, and by name every result is the same apart from the new test (pass). The 33 fail the same way on main on this Mac: test_appimage_package_retry, test_appimage_player_build, test_collect_wide, test_control, test_cpm_discovery, test_crash_dialog, test_crash_record, test_env_on, test_game_layout, test_lift_cleanup_error, test_linux_preflight, test_longshot_ctl, test_low_memory_notice, test_make_game_cache, test_mem_gate, test_mem_gate_children, test_mirror_trim, test_oot_state_tap, test_options_budget_once, test_options_path, test_pcache_header_read, test_pipeline_cache_file, test_pipeline_cache_save, test_pipeline_play_cache, test_pipeline_tour, test_prof_symbols, test_program_cache_cleanup, test_program_cache_one_variant, test_readback_late, test_report_run, test_split_giants, test_vk_pgo, test_walk_key. **Not tested:** in the game, on any platform (neither hazard can be produced on demand: it needs a GPU stall over 5 s, or the GPU more than 4 frames behind with no window). Not built on Windows (llvm-mingw) or Linux. The code has no platform branch, so it runs the same on both. **Must be tested:** - Windows and Linux, any GPU, with the Khronos validation layer installed: build this PR (head 90f6c3e3) and main aa95d35f the same way and run `python -I -B tests/run_all.py`. Then start each with `HOS_HEADLESS=1 RX_VK_FSR=1 RX_VK_REACTIVE=1 RX_VK_VALIDATION=1` (no window, FSR 3.1, the reactive mask) and play to the title and into the field. Expect every check to pass, and no validation error on this PR that main does not also show. A read-back that runs out of its 5 s wait cannot be made on demand (by hand: test request T-NTFW) ## Risks **What could break:** a read-back after a GPU stall now waits for the stall to end instead of going on. A real hang still ends at the GPU hang watch (`RX_VK_GPU_HANG_SEC`, 30 s). The upscalers' images and the headless overlays are kept until the GPU has passed them, at most a few frames longer than before. **Turning it off:** revert the commit **Compatibility:** Nothing changes ## 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. (Test request T-NTFW.) - [x] Rebased on current `main` (main aa95d35f, head `90f6c3e3`). - [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. - [x] A game-free test added for the fix, failing on `main` and passing here. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened.
fix(vk): free on the GPU's progress, not on a time or a frame count: read-back timeouts and the upscalers' frees
Some checks failed
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
Third-party parts / The same as upstream (pull_request) Has been skipped
Details
CI / Conventional Commit title (pull_request) Successful in 3s
Details
CI / Workflow lint (actionlint) (pull_request) Successful in 6s
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 8s
Details
PR description / Description follows the template (pull_request_target) Successful in 6s
Details
Website / Website on Cloudflare (pull_request_target) Has been skipped
Details
90f6c3e35f 
Some frees waited for a 5 s limit or a few frames, not for the GPU: a hazard on every GPU, reached when the GPU runs
late. Nothing is freed earlier than before; only later where the GPU had not finished.

- Read-backs: a read-back whose 5 s wait ran out left rb_pool and rb_fence to be reset, and rb_cmd begun again,
  by the next read-back with no wait while the GPU could still run it: a pool with a pending command buffer and a
  fence of a pending submit must not be reset, and drivers reuse a reset pool's command memory. Now they wait for
  it, without a limit, before they are reset (rb_pending, readback_settle). The batch's textures wait for the
  submission after it (last_value), as its staging buffers already did: the copies may still read them.
- Frees counted in frames: what the reactive mask, the temporal upscalers (DLSS and FSR 4 through temporal_later)
  and the FSR 3 inputs let go was freed 4 frames on. With no window (HOS_HEADLESS) presents render offscreen and
  nothing waits for the present ring; only the 48-slot recording ring bounds how far behind the GPU is, many
  frames when a frame has few recordings. They now wait for the timeline value that followed them
  (vk_retirement_value) as well, never for 0, as vk_fsr3.cpp does. Likewise the overlays' dead list with no window
  (RX_VK_SHOT_MENU's overlays are recorded on the timeline, and idle() counts frames with no wait for the GPU).

TAAU's replaced histories (120 frames) are left as they are: 120 frames are more recordings than the ring holds.

tests/test_async_safe_frees.py runs the read-back against a GPU that does not finish in time and the three later()
lists on a timeline of the test's; tests/test_ui_texture_upload.py gains the headless case.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <[email protected]>
mooki changed title from WIP: fix(vk): free on the GPU's progress, not on a time or a frame count: read-back timeouts and the upscalers' frees to fix(vk): free on the GPU's progress, not on a time or a frame count: read-back timeouts and the upscalers' frees 2026-11-15 12:00:14 +00:00
Some checks failed
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
Third-party parts / The same as upstream (pull_request) Has been skipped
Details
CI / Conventional Commit title (pull_request) Successful in 3s
Details
CI / Workflow lint (actionlint) (pull_request) Successful in 6s
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 8s
Details
PR description / Description follows the template (pull_request_target) Successful in 6s
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.
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/async-safe-frees:mooki-fix/async-safe-frees'
git switch 'mooki-fix/async-safe-frees'
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
1 participant
Notifications
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!788
No description provided.