[perf][LOW] Narrow per-dispatch UI barrier to an image-subresource barrier (full removal: #47) #48

Closed
opened 2026-06-16 16:51:31 +02:00 by jorijnvdgraaf · 0 comments

Subsystem: UI compute pipeline
Location: implementations/Crafter.Graphics-UI.cpp:181-197
Impact: LOW-MEDIUM · Effort: Small
Related: #47 (pass fusion — the way to eliminate these barriers)

Scope note: this issue is now only the cheap, non-breaking barrier-tightening. Eliminating the barriers entirely (by fusing consecutive passes into one dispatch) is tracked in #47 — do not duplicate that work here.

Problem

Dispatch() inserts a global VkMemoryBarrier (SHADER_WRITE -> SHADER_READ|WRITE) before every dispatch after the first (firstDispatchThisFrame_). A typical quads/circles/images/text frame pays 3 of these. As a VkMemoryBarrier it is a queue-wide memory dependency that flushes/invalidates all shader caches, broader than the actual hazard (a read-modify-write of the single swapchain storage image).

The barrier is required for correctness as written — all passes RMW the same image, later overdraws earlier — so it cannot simply be removed here.

Proposed fix (non-breaking)

Narrow the global VkMemoryBarrier to a VkImageMemoryBarrier scoped to the swapchain image's subresource (COMPUTE_SHADER -> COMPUTE_SHADER, SHADER_WRITE -> SHADER_READ|WRITE). Same correctness, narrower cache flush — unrelated resources are no longer invalidated.

Honest limit of this fix

This is a narrower cache flush only — the execution dependency stays compute->compute over the whole queue, so it does NOT let the passes overlap. The real serialization win comes from not issuing the barriers at all, which requires fusing the passes (#47's DispatchFused). Treat this issue as the small, safe, independent improvement that is worth doing regardless of whether/when #47 lands.

Do NOT

Replace it with a VkBufferMemoryBarrier — wrong barrier type for an image hazard; would corrupt output.

**Subsystem:** UI compute pipeline **Location:** `implementations/Crafter.Graphics-UI.cpp:181-197` **Impact:** LOW-MEDIUM · **Effort:** Small **Related:** #47 (pass fusion — the way to *eliminate* these barriers) > Scope note: this issue is now **only** the cheap, non-breaking barrier-tightening. Eliminating the barriers entirely (by fusing consecutive passes into one dispatch) is tracked in #47 — do not duplicate that work here. ### Problem `Dispatch()` inserts a global `VkMemoryBarrier` (SHADER_WRITE -> SHADER_READ|WRITE) before every dispatch after the first (`firstDispatchThisFrame_`). A typical quads/circles/images/text frame pays 3 of these. As a `VkMemoryBarrier` it is a queue-wide memory dependency that flushes/invalidates all shader caches, broader than the actual hazard (a read-modify-write of the single swapchain storage image). The barrier is **required for correctness** as written — all passes RMW the same image, later overdraws earlier — so it cannot simply be removed here. ### Proposed fix (non-breaking) Narrow the global `VkMemoryBarrier` to a `VkImageMemoryBarrier` scoped to the swapchain image's subresource (COMPUTE_SHADER -> COMPUTE_SHADER, SHADER_WRITE -> SHADER_READ|WRITE). Same correctness, narrower cache flush — unrelated resources are no longer invalidated. ### Honest limit of this fix This is a **narrower cache flush only** — the execution dependency stays compute->compute over the whole queue, so it does NOT let the passes overlap. The real serialization win comes from not issuing the barriers at all, which requires fusing the passes (#47's `DispatchFused`). Treat this issue as the small, safe, independent improvement that is worth doing regardless of whether/when #47 lands. ### Do NOT Replace it with a `VkBufferMemoryBarrier` — wrong barrier type for an image hazard; would corrupt output.
jorijnvdgraaf changed title from [perf][MEDIUM] Full-image compute->compute barrier between every UI dispatch to [perf][LOW] Narrow per-dispatch UI barrier to an image-subresource barrier (full removal: #47) 2026-06-16 18:47:30 +02:00
Sign in to join this conversation.
No milestone
No project
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
Catcrafts/Crafter.Graphics#48
No description provided.