eglantine-cirakg/src/video_core/buffer_cache, branch nx2

nx2: fewer render pass splits on tiled GPUs, log failed GPU waits (Pokopia) (#361)

2026-11-03T06:29:23+00:00

* buffer_cache: don't end the render pass after mapped buffer uploads Every upload set any_buffer_uploaded, and the next draw or dispatch then recorded a transfer-to-shader barrier outside the render pass. On Vulkan the uploads are mapped: each copy either records its own barriers (CopyBuffer with barrier set) or goes to the upload command buffer, which ends with a barrier before the frame's commands run. The extra barrier only ended the render pass. On tiled GPUs every such split writes the attachments out and reads them back. Pokopia's first gameplay scene had ~50 of these splits a frame. Without them, an M3 MacBook Air (MoltenVK, 1x docked) goes from ~35 to ~29.5 ms of GPU time a frame and from 28.5 to 32 fps. OpenGL uploads immediately and keeps the barrier. Assisted-by: Claude Opus 5.5 (profiling, implementation and commit message) * vulkan: log a failed GPU wait before it ends the process When the device is lost, vkWaitSemaphores in MasterSemaphore::Wait returns VK_ERROR_DEVICE_LOST and the exception goes uncaught on the fence thread or the GPU thread, so the process aborts without a line in the log: ReportLoss is only reached from submit and present. A Pokopia crash on macOS left the log ending a second before the abort, with no hint that the GPU was lost. Log the wait's result before rethrowing. On macOS, MoltenVK prints the Metal reason (a GPU hang or page fault) to stderr only. Assisted-by: Claude Opus 5.5 (diagnosis, implementation and commit message)

Merge pull request #334 from snowstormxd/codex/upstream-mkw-test

2026-11-02T22:36:01+00:00

MKW performance improvements

Merge pull request #337 from Sssnowyyy/nx2-review-fixes

2026-11-02T22:18:21+00:00

nx2: fix pokopia regressions, textures that handle shader computes, and more

Merge pull request #113 from ymatrix1/fix/storage-buffers-32

2026-11-02T22:14:50+00:00

buffer_cache: allow 32 storage buffers per stage

nx2: rearm clean read areas when the GPU writes them again

2026-11-02T20:51:11+00:00

Port the coherency changes from alarok/Eglantine 77fc365f2 without its diagnostic framework or shutdown changes. Only GPU-dirty CPU reads become permanently preflushable, clean areas can be trapped on the next write, non-core readers avoid indexing core arrays, and collected CPU writes precede readback. Assisted-by: Codex (source review, selective integration and verification) (cherry picked from commit b64e211957180aa218ec6d9a3bcb020332279c3f)

buffer_cache: fix the already-disabled check for uniform buffers

2026-11-02T19:53:47+00:00

DisableGraphicsUniformBuffer tested !current.buffer_id to detect a binding that is already NULL_BINDING. SlotId converts to true unless it is the invalid id, and NULL_BUFFER_ID is BufferId{0}, so the check was false for NULL_BINDING and the early return never triggered. Compare against NULL_BUFFER_ID instead. Follow-up to 46b2577bf7. Assisted-by: Claude Sonnet 5.5 (implementation and commit message)

vulkan: repack 69-byte vertices only when needed

2026-11-02T19:53:47+00:00

SetVertexRepackLayout returned old_mask | new_mask, which stays non-zero on every draw that uses a 69-byte binding. PrepareDraw then re-dirtied the vertex buffers and vertex input each time, so the repack compute pass ran and the render pass ended once per draw, which is costly on tiled GPUs. Return old_mask ^ new_mask so only a layout change re-dirties the bindings. The repacked copy only stays valid while the source data is unchanged, so the buffer cache now flags the vertex buffers overlapping a CPU write, inline or DMA write, or GPU write, and re-dirties the repacked ones before binding. Command buffer submission already invalidates all vertex buffer state, which keeps the staging copy within its tick. Also pass the source buffer size to the repack pass and clamp the word-rounded storage descriptor range to it; it could run up to three bytes past the end of the buffer. A binding that does not fit is skipped like one over the device limits. Follow-up to e38b738b84. Assisted-by: Claude Sonnet 5.5 (implementation and commit message)

video_core/buffer_cache: reuse unchanged small uniform buffers within command buffer

2026-11-02T18:58:38+00:00

(cherry picked from commit 4aa5cd89fd1862751b3297036f2d21a0dc924b23) (cherry picked from commit f1bdd5b13a1bdca81243b4aa1d8529f0485d3671)

nx2: read GPU-written command lists from copies instead of draining

2026-11-02T16:24:19+00:00

The trees fix (#52) drains the split and flushes for every command list on a GPU-written page: in a Mario Kart World race ~13,500 lists and ~400 GPU round trips a second, during which the back has nothing to do. The replay ran at ~40 fps instead of ~45. The front now marks the pages those lists are on. The buffer cache notes writes to them; after a compute dispatch or DMA copy that writes one it copies the page into host memory and submits. The front waits for the back only up to the last compute or copy work it sent (not everything queued), then reads the copy once the GPU is done with it. Pages the GPU wrote once, long before, and the CPU now writes lists to have no copy: their first list drains and flushes the whole page, which is then read from guest memory until GPU work writes it again. CPU writes and inline uploads reach guest memory, so they keep such a page synced but make a copy stale. A page a draw writes always drains. Mario Kart World time-trial replay, Radeon 780M: ~40 -> ~45 fps, trees drawn, no list drains left.

buffer_cache: allow 32 storage buffers per stage

2026-11-02T15:03:06+00:00

Native Switch 2 compute shaders (such as Donkey Kong Bananza) bind up to 18 global memory ranges, causing out-of-bounds binding errors: HW.GPU buffer_cache.h:BindComputeStorageBuffer: Storage buffer index 16 exceeds maximum storage buffer count HW.GPU buffer_cache.h:BindComputeStorageBuffer: Storage buffer index 17 exceeds maximum storage buffer count followed by GPU driver access violations (0xc0000005). The enabled and written storage buffer bitmasks (enabled_compute_storage_buffers and written_compute_storage_buffers) are already u32, so widening NUM_STORAGE_BUFFERS from 16 to 32 fits naturally within the existing 32-bit masks.