fix(vk): a recording without a draw stream is submitted instead of crashing #552

Merged

HumanBean merged 2 commits from zeldaootr/Longshot:draw-flush-empty-stream into main 2026-11-15 17:53:06 +00:00

Conversation 4 Commits 2 Files changed 3 +11 -2

zeldaootr commented 2026-11-14 19:17:17 +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

When the GPU's host-visible memory ran out right at the start of a frame's recording, the renderer then read past an empty list while finishing that recording and could crash the game.

How to reproduce

Seen on: Linux x86-64, game-free (the real draw_flush_recording with a stand-in buffer maker); not reproducible on demand in the game, since it needs host-visible memory to run out at a recording's start
Settings and switches: defaults
Steps: on main aa95d35f with this PR's test case added (d6ec2f17), run python -I -B tests/test_draw_stream_visibility.py --cxx g++ --headers <Vulkan-Headers/include>: its first-stream-failure case makes the slot's first stream buffer fail
Expected: the recording is flushed with nothing to flush and submitted
Actual: fixture.exe first-stream-failure coherent died with <Signals.SIGSEGV: 11>: the flush reads r.streams[0] of an empty vector

What changed

Finishing a recording now flushes only the streams the slot has, so a recording whose first stream could not be made is submitted without its draws instead of crashing.

• vk: draw_flush_recording() in gpu/vk/vk_draw.cpp stops at the streams the slot has: when draw_begin_recording could not make the slot's first stream, there are none, and the loop used to read r.streams[0] of an empty vector.
• tests: tests/draw_stream_visibility_test.cpp gets a first-stream-failure case (the first stream's buffer cannot be made; the recording must submit with nothing to flush), and tests/test_draw_stream_visibility.py runs it.

Measurements

Verdict: fixed in the game-free test (crashes on main, passes with this PR, two interleaved rounds); no regression on a tester's Steam Deck (no crash or fault, fps 20.6 and 21.2 against main's 19.9 and 20.2).

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_draw_stream_visibility.py --cxx g++ --headers <Vulkan-Headers/include> at the test-only commit d6ec2f17 (main aa95d35f plus the test) and at 21b94e1a, twice each, alternating
How to reproduce: check out each commit and run the command above

	Before: main @ aa95d35f (with the test, d6ec2f17)	After: this PR @ 21b94e1a
first-stream-failure case (both rounds the same)	crashes (SIGSEGV)	passes

d6ec2f17 r1: subprocess.CalledProcessError: Command '[.../fixture.exe', 'first-stream-failure', 'coherent']' died with <Signals.SIGSEGV: 11>. (exit 1)
21b94e1a r1: PASS: a recording whose first stream could not be made (exit 0)
d6ec2f17 r2: ... died with <Signals.SIGSEGV: 11>. (exit 1)
21b94e1a r2: PASS: a recording whose first stream could not be made (exit 0)

In the game, dukenheimer's Steam Deck run for test request T-E85L (pass; #552 (comment)): this PR's head d9edb33f (the same change, on main 7ff5256e, in a build with #550 to #558 merged) against main 7ff5256e, Steam Deck OLED (SteamOS 3.9.5, Mesa 26.2.0-devel, Game Mode, docked, stock clocks), two 5-minute runs each through Kokiri Forest, Hyrule Field and Kokiri again. No crash, device loss, fault or GPU stall in any run; fps 20.6 and 21.2 with it against 19.9 and 20.2 on main; the arrival pictures match main's, nothing missing. The failure itself needs memory to run out, and nothing in these runs shows whether a first upload stream ever failed (the change logs nothing); that Deck was short of memory in every run (about 4 GB swapped, MemAvailable down to 280 to 880 MB) and nothing crashed. So this is a non-regression result; the fix itself is shown by the game-free test.

Flags and settings

None

Testing

Tested: Linux x86-64, game-free. The new case fails (SIGSEGV) on the test-only commit d6ec2f17 and passes at 21b94e1a (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 at both commits. At the tip, the 109 checks that read gpu/vk/vk_draw.cpp or the changed test: 106 passed, 1 skipped, and 2 failed that fail or are skipped by OS on main aa95d35f too (test_pipeline_tour; test_shader_module_guard, a Windows-only check run here by name). Before the rebase the same at 509f122f and d9edb33f (main 7ff5256e). Steam Deck: dukenheimer's run for T-E85L, in Measurements.

Not tested: The out-of-memory case in the game (not reproducible on demand). Windows in the game.

Must be tested: None

Risks

What could break: one bound added to a loop; a slot with streams flushes exactly as before.

Turning it off: revert the commit

Compatibility: Nothing changes

Issues

None filed.

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 109 checks that read the changed files 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.
• A check under tests/ that reads changed source updated in this PR, not weakened.
• Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. Not built whole after the rebase; gpu/vk/vk_draw.cpp at 21b94e1a checked whole (-fsyntax-only -Wall -Wextra, the build's defines) with clang 23.1.5 for Linux and llvm-mingw 20261104 for Windows: the same diagnostics as main aa95d35f's (102 and 103), none new; on Linux both stop at the same narrowing error in a line this PR does not touch. Before the rebase, the combined branch 27553c83 linked longshot_vk.dll (llvm-mingw 20261104, RX_VK_ONLY=1 RX_RELEASE=1 RX_TARGET=windows) and longshot_vk.so.

**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 When the GPU's host-visible memory ran out right at the start of a frame's recording, the renderer then read past an empty list while finishing that recording and could crash the game. ## How to reproduce **Seen on:** Linux x86-64, game-free (the real `draw_flush_recording` with a stand-in buffer maker); not reproducible on demand in the game, since it needs host-visible memory to run out at a recording's start **Settings and switches:** defaults **Steps:** on `main` aa95d35f with this PR's test case added (d6ec2f17), run `python -I -B tests/test_draw_stream_visibility.py --cxx g++ --headers <Vulkan-Headers/include>`: its `first-stream-failure` case makes the slot's first stream buffer fail **Expected:** the recording is flushed with nothing to flush and submitted **Actual:** `fixture.exe first-stream-failure coherent died with <Signals.SIGSEGV: 11>`: the flush reads `r.streams[0]` of an empty vector ## What changed Finishing a recording now flushes only the streams the slot has, so a recording whose first stream could not be made is submitted without its draws instead of crashing. - vk: `draw_flush_recording()` in `gpu/vk/vk_draw.cpp` stops at the streams the slot has: when `draw_begin_recording` could not make the slot's first stream, there are none, and the loop used to read `r.streams[0]` of an empty vector. - tests: `tests/draw_stream_visibility_test.cpp` gets a `first-stream-failure` case (the first stream's buffer cannot be made; the recording must submit with nothing to flush), and `tests/test_draw_stream_visibility.py` runs it. ## Measurements **Verdict:** fixed in the game-free test (crashes on `main`, passes with this PR, two interleaved rounds); no regression on a tester's Steam Deck (no crash or fault, fps 20.6 and 21.2 against main's 19.9 and 20.2). 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_draw_stream_visibility.py --cxx g++ --headers <Vulkan-Headers/include>` at the test-only commit d6ec2f17 (main aa95d35f plus the test) and at 21b94e1a, twice each, alternating How to reproduce: check out each commit and run the command above | | Before: main @ aa95d35f (with the test, d6ec2f17) | After: this PR @ 21b94e1a | |---|---|---| | `first-stream-failure` case (both rounds the same) | crashes (SIGSEGV) | passes | ``` d6ec2f17 r1: subprocess.CalledProcessError: Command '[.../fixture.exe', 'first-stream-failure', 'coherent']' died with <Signals.SIGSEGV: 11>. (exit 1) 21b94e1a r1: PASS: a recording whose first stream could not be made (exit 0) d6ec2f17 r2: ... died with <Signals.SIGSEGV: 11>. (exit 1) 21b94e1a r2: PASS: a recording whose first stream could not be made (exit 0) ``` In the game, dukenheimer's Steam Deck run for test request T-E85L (pass; https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/552#issuecomment-21285): this PR's head d9edb33f (the same change, on main 7ff5256e, in a build with #550 to #558 merged) against main 7ff5256e, Steam Deck OLED (SteamOS 3.9.5, Mesa 26.2.0-devel, Game Mode, docked, stock clocks), two 5-minute runs each through Kokiri Forest, Hyrule Field and Kokiri again. No crash, device loss, fault or GPU stall in any run; fps 20.6 and 21.2 with it against 19.9 and 20.2 on main; the arrival pictures match main's, nothing missing. The failure itself needs memory to run out, and nothing in these runs shows whether a first upload stream ever failed (the change logs nothing); that Deck was short of memory in every run (about 4 GB swapped, MemAvailable down to 280 to 880 MB) and nothing crashed. So this is a non-regression result; the fix itself is shown by the game-free test. ### Flags and settings None ## Testing **Tested:** Linux x86-64, game-free. The new case fails (SIGSEGV) on the test-only commit d6ec2f17 and passes at 21b94e1a (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 at both commits. At the tip, the 109 checks that read `gpu/vk/vk_draw.cpp` or the changed test: 106 passed, 1 skipped, and 2 failed that fail or are skipped by OS on `main` aa95d35f too (`test_pipeline_tour`; `test_shader_module_guard`, a Windows-only check run here by name). Before the rebase the same at 509f122f and d9edb33f (main 7ff5256e). Steam Deck: dukenheimer's run for T-E85L, in Measurements. **Not tested:** The out-of-memory case in the game (not reproducible on demand). Windows in the game. **Must be tested:** None ## Risks **What could break:** one bound added to a loop; a slot with streams flushes exactly as before. **Turning it off:** revert the commit **Compatibility:** Nothing changes ## Issues None filed. ## 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 109 checks that read the changed files 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. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [x] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. Not built whole after the rebase; `gpu/vk/vk_draw.cpp` at 21b94e1a checked whole (`-fsyntax-only -Wall -Wextra`, the build's defines) with clang 23.1.5 for Linux and llvm-mingw 20261104 for Windows: the same diagnostics as `main` aa95d35f's (102 and 103), none new; on Linux both stop at the same narrowing error in a line this PR does not touch. Before the rebase, the combined branch 27553c83 linked `longshot_vk.dll` (llvm-mingw 20261104, `RX_VK_ONLY=1 RX_RELEASE=1 RX_TARGET=windows`) and `longshot_vk.so`.

zeldaootr added 2 commits 2026-11-14 19:17:18 +00:00

test: a recording whose first stream could not be made is flushed and submitted ... 509f122f8d

Assisted-by: Claude

vk: draw_flush_recording flushes no stream when the slot has none ... d9edb33f79

Assisted-by: Claude

zeldaootr commented 2026-11-14 19:31:02 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Filled in: the full game-free suite on the combined branch, the Windows and Linux builds, and the test request T-E85L. Still work in progress until a Steam Deck run is in.

Filled in: the full game-free suite on the combined branch, the Windows and Linux builds, and the test request T-E85L. Still work in progress until a Steam Deck run is in.

dukenheimer commented 2026-11-15 00:04:20 +00:00

Contributor

• Copy link
• Copy Markdown

Test request T-E85L: pass

Built from main 7ff5256e with #550 to #558 merged in order (all clean); this PR at its head d9edb33f. The comparison is main 7ff5256e.
Setup and method below; the runs are #551's series, where the combined build ran third and fourth.

Result

run	build	fps: Kokiri / Field / Kokiri again	fps, the whole 5 minutes	crash, device lost or fault, GPU stalled
1	main	20.3 / 19.5 / 19.9	19.9	none
3	combined (this PR)	21.7 / 19.9 / 19.5	20.6	none
4	combined (this PR)	21.4 / 21.1 / 21.2	21.2	none
6	main	19.3 / 20.6 / 22.0	20.2	none

• No crash in either run with this PR; fps like main's (20.6 and 21.2 against 19.9 and 20.2).
• The arrival pictures (Kokiri, the Field, Kokiri again) match main's: nothing missing.
• The kernel's amdgpu lines were only the display's "Losing delta precision while programming shaper LUT" notices, 6 a start, in every
  run.

As the request says, the failure itself needs memory to run out, and nothing here shows whether a first upload stream ever failed:
the change logs nothing. This Deck was short of memory in every run at these settings (about 4 GB swapped, MemAvailable down to
280-880 MB), and nothing crashed.

Setup

• 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. Game Mode, docked, stock clocks.
• Builds: main 7ff5256e; main + this PR alone (the renderer built from the PR's head); and a combined build of main + #550 to #558,
  merged in order, all clean. All built for x86-64-v3 with the release play profile and LLVM 23.1.5. One test folder (warm caches) with
  the binaries swapped; the shader caches' stamp is the same for all three.
• Settings: main's own defaults on this Deck, the options file its first start wrote. Quality preset Auto (this PC), output
  1280x720, Render resolution 50% (640x360), the game's own upscaler, frame generation off, VRAM budget 2.2 GB.
• The same 5 minutes each run, through the control bridge: Continue into Kokiri Forest, 110 s there, the debug teleport to
  HyruleField_Child (the Lost Woods bridge), 110 s, the teleport back to KokiriForest_Child, 50 s.
  • Link stood at each arrival point while the camera turned round, one way then the other: the same inputs every run. Walking set
    off events that blocked the teleports.
  • The game autosaves at each arrival, so every run continued from the same Kokiri arrival point.
• Measured: fps is the bridge's status every 5 s (the game's frames over the last second), averaged per area. A picture at each
  arrival.
• Order: main, main + #551, combined, combined, main + #551, main.

The arrival pictures, all six runs (Kokiri, the Field, Kokiri again):

Test request T-E85L: pass Built from main 7ff5256e with #550 to #558 merged in order (all clean); this PR at its head d9edb33f. The comparison is main 7ff5256e. Setup and method below; the runs are #551's series, where the combined build ran third and fourth. **Result** | run | build | fps: Kokiri / Field / Kokiri again | fps, the whole 5 minutes | crash, device lost or fault, GPU stalled | |---|---|---|---|---| | 1 | main | 20.3 / 19.5 / 19.9 | 19.9 | none | | 3 | combined (this PR) | 21.7 / 19.9 / 19.5 | 20.6 | none | | 4 | combined (this PR) | 21.4 / 21.1 / 21.2 | 21.2 | none | | 6 | main | 19.3 / 20.6 / 22.0 | 20.2 | none | - No crash in either run with this PR; fps like main's (20.6 and 21.2 against 19.9 and 20.2). - The arrival pictures (Kokiri, the Field, Kokiri again) match main's: nothing missing. - The kernel's amdgpu lines were only the display's "Losing delta precision while programming shaper LUT" notices, 6 a start, in every run. As the request says, the failure itself needs memory to run out, and nothing here shows whether a first upload stream ever failed: the change logs nothing. This Deck was short of memory in every run at these settings (about 4 GB swapped, MemAvailable down to 280-880 MB), and nothing crashed. **Setup** - 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. Game Mode, docked, stock clocks. - **Builds:** main 7ff5256e; main + this PR alone (the renderer built from the PR's head); and a combined build of main + #550 to #558, merged in order, all clean. All built for x86-64-v3 with the release play profile and LLVM 23.1.5. One test folder (warm caches) with the binaries swapped; the shader caches' stamp is the same for all three. - **Settings:** main's own defaults on this Deck, the options file its first start wrote. Quality preset Auto (this PC), output 1280x720, Render resolution 50% (640x360), the game's own upscaler, frame generation off, VRAM budget 2.2 GB. - **The same 5 minutes each run, through the control bridge:** Continue into Kokiri Forest, 110 s there, the debug teleport to HyruleField_Child (the Lost Woods bridge), 110 s, the teleport back to KokiriForest_Child, 50 s. - Link stood at each arrival point while the camera turned round, one way then the other: the same inputs every run. Walking set off events that blocked the teleports. - The game autosaves at each arrival, so every run continued from the same Kokiri arrival point. - **Measured:** fps is the bridge's status every 5 s (the game's frames over the last second), averaged per area. A picture at each arrival. - **Order:** main, main + #551, combined, combined, main + #551, main. The arrival pictures, all six runs (Kokiri, the Field, Kokiri again): 

sheet-zt2.png

1.5 MiB

zeldaootr commented 2026-11-15 00:25:12 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Thank you for the Deck run, dukenheimer: your result is in the description as you reported it, including its limits. Marking this ready for review.

Thank you for the Deck run, dukenheimer: your result is in the description as you reported it, including its limits. Marking this ready for review.

zeldaootr changed title from WIP: fix(vk): a recording without a draw stream is submitted instead of crashing to fix(vk): a recording without a draw stream is submitted instead of crashing 2026-11-15 00:25:14 +00:00

mooki added the

area/renderer

kind

bug

platform/linux

platform/windows

priority

high

labels 2026-11-15 13:55:34 +00:00

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

Author

Contributor

• Copy link
• Copy Markdown

Rebased onto main aa95d35f with no conflict (the same two changes, git patch-id; commits now under the noreply identity) and the description moved to the current template.
The test was run again on the new base (SIGSEGV at the test-only commit, pass at the tip, two rounds, g++ and clang); dukenheimer's T-E85L Deck run still holds as a non-regression result: main changed vk_draw.cpp since 7ff5256e (#404, #608, #721, #415, #729, #761) but not draw_flush_recording(), the one function this PR touches.

Rebased onto `main` aa95d35f with no conflict (the same two changes, `git patch-id`; commits now under the noreply identity) and the description moved to the current template. The test was run again on the new base (SIGSEGV at the test-only commit, pass at the tip, two rounds, g++ and clang); dukenheimer's T-E85L Deck run still holds as a non-regression result: `main` changed `vk_draw.cpp` since 7ff5256e (#404, #608, #721, #415, #729, #761) but not `draw_flush_recording()`, the one function this PR touches.

zeldaootr force-pushed draw-flush-empty-stream from d9edb33f79 to 21b94e1ab2 2026-11-15 16:43:50 +00:00 Compare

HumanBean merged commit b7a014b82d into main 2026-11-15 17:53:06 +00:00

HumanBean referenced this pull request from a commit 2026-11-15 17:53:08 +00:00

fix(vk): a recording without a draw stream is submitted instead of crashing (#552)

HumanBean deleted branch draw-flush-empty-stream 2026-11-15 17:53:09 +00:00

mooki added

priority

critical

and removed

priority

high

labels 2026-11-15 18:06:02 +00:00

Some checks are pending

Hide checks

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

Details

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

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

Website / Website on Cloudflare (pull_request_target) Has been skipped

Details

Some workflows are waiting to be reviewed.

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

No description provided.