Emit spec-compliant SPIR-V under the Vulkan memory model - #10016
Open
kvark wants to merge 4 commits into
Open
Conversation
The cooperative matrix support (gfx-rs#8251) started declaring the Vulkan memory model, but the rest of the generated code kept GLSL450-model assumptions, leaving storage and workgroup accesses private and barriers without availability/visibility operations (gfx-rs#8805). The writer now decides the memory model up front - when a module uses cooperative matrices, or when the new `spv::Options::use_vulkan_memory_model` requests it (gfx-rs#1545) - and under the model: - storage and workgroup loads/stores (including cooperative matrix loads/stores and the workgroup zero-init polyfill) carry `NonPrivatePointer` with a `MakePointerVisible`/`MakePointerAvailable` scope: QueueFamily for `@coherent` globals, Workgroup otherwise; - control and memory barriers add `MakeAvailable | MakeVisible` semantics; - atomics and storage barriers use QueueFamily scope instead of Device, which would require the `vulkanMemoryModelDeviceScope` feature; - the `Coherent` and `Volatile` decorations, forbidden by the model, are replaced by per-access memory operands, with volatile atomics using the `Volatile` memory semantics bit. The new wgsl-vulkan-memory-model test exercises the opt-in path with coherent, volatile, and plain storage buffers, workgroup memory, atomics, and both barriers; the output and the regenerated cooperative matrix snapshots pass spirv-val under Vulkan 1.1 rules. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WRD8L4KyVGxJfKTqkX3gmh
Availability and visibility operations only matter for data some invocation of the dispatch may write; for globals no written entry point touches, the API-side domain operation before the dispatch already made the contents visible, and private accesses preserve first-level caching. Globals with explicit memory decorations are exempt: @volatile in particular exists for data modified from outside the dispatch. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WRD8L4KyVGxJfKTqkX3gmh
`enable wgpu_memory_fence;` unlocks `storageFence()` and `workgroupFence()`: acquire/release memory ordering without execution synchronization, lowering to the IR's existing fence-only `Statement::MemoryBarrier`. Unlike the barrier built-ins, fences carry no uniform-control-flow requirement, so producer/consumer protocols can fence inside non-uniform code such as spin loops. On SPIR-V this is `OpMemoryBarrier` (with availability/visibility semantics under the Vulkan memory model); Metal and HLSL have no fence-only form and keep lowering to execution barriers, so portable code should stay uniform. SPIR-V ingestion of `OpMemoryBarrier` now also round-trips through WGSL as fences instead of being strengthened into control barriers. On Metal, the `@volatile` decoration is now supported (`volatile` device pointers), and `@coherent` below MSL 3.2 fails with a clear error instead of emitting a qualifier older Metal cannot compile. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WRD8L4KyVGxJfKTqkX3gmh
Replaces the confusable pair of booleans (use_vulkan_memory_model / vulkan_memory_model) on the writer: the option keeps its name, and the per-module decision is now `memory_model: spirv::MemoryModel`, which the module header emits directly. No output changes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WRD8L4KyVGxJfKTqkX3gmh
kvark
force-pushed
the
vulkan-memory-model-compliance
branch
from
August 5, 2026 05:46
bdb3fee to
8aba011
Compare
kvark
marked this pull request as ready for review
August 5, 2026 05:50
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Connections
Closes #8805
Related to #1545
Description
The cooperative matrix support (#8251) started declaring the Vulkan memory model, but the rest of the generated code kept GLSL450-model assumptions, leaving storage and workgroup accesses private and barriers without availability/visibility operations (#8805).
This PR aims to expose a pathway to write megakernels in WGSL (on native).
It's written by Claude Fable under my supervision.
Testing
Comes with tests
Squash or Rebase?
Squash is fine
Checklist
wgpumay be affected behaviorally.CHANGELOG.mdentries for the user-facing effects of this change are present.