What this tracks
Whether GPU hardware and vendor shading-language APIs have converged enough to support one
generic shader "kernel" type with intrinsics — texture sampling, ray queries, wave ops,
tensor/cooperative-matrix ops, and meshlet spawning all as callable intrinsics from any shader —
instead of today's ~16 separate shader-stage entry points (vertex / pixel / compute / mesh / task /
ray-gen / closest-hit / any-hit / miss / callable / intersection / amplification / ...).
This is the closing, explicitly speculative idea from Sebastian Aaltonen's Reducing Graphics API
Complexity talk (youtube.com/watch?v=aQv9pUl9PBM), discussed alongside #691 on 2026-08-08. It is
not part of #691's phased Vulkan roadmap — that roadmap (see ADR 0010/0011, especially the
root-data-as-pointer and thin-PSO decisions added in §4/§5) targets what's achievable on
current-generation hardware. This issue exists so we notice if that changes, the same way #688
watches C++26 reflection toolchain support rather than trying to build against it early.
Why this isn't picked up now
Per the talk itself, this needs hardware/command-processor microcode changes across vendors, not
just new API surface. The building blocks that exist today are real steps toward it, but the core
mechanism — spawn an arbitrary wave/kernel from any shader stage with a single GPU-pointer
argument, kick meshlets directly to the rasterizer from arbitrary compute — has no public vendor
timeline as of 2026-08.
What's already landed (partial progress toward this)
- Inline ray queries (
RayQuery / rayQueryEXT, Vulkan RT 1.1 / DXR 1.1) — callable from any
shader stage without a dedicated ray-generation shader. The clearest precedent for "intrinsic,
not a new shader type."
- Wave intrinsics generalized as ordinary intrinsics rather than a separate shader-model tier
(SM6.x wave ops, Vulkan subgroup ops).
- Tensor / cooperative-matrix ops added as intrinsics in existing shader stages instead of a
separate DirectML-shaped API (VK_KHR_cooperative_matrix, SM6.8 wave-matrix).
- Mesh shaders (task + mesh) — a real step toward GPU-driven kicking, but still a fixed,
separate entry-point pair, not a general "kick from anywhere" mechanism.
Watch for / triggers to reopen this as real, scoped work
- A Khronos Vulkan (or DirectX shader-model) proposal for generic wave/kernel spawning from
arbitrary shader stages, taking a single opaque-pointer argument.
- Meshlet-kick-to-rasterizer exposed from a non-task shader stage — generalized beyond the fixed
task → mesh pipeline.
- A GPU vendor (NVIDIA / AMD / Intel / Apple) SIGGRAPH/GDC talk or public driver roadmap describing
command-processor support for this.
- Public commentary from Aaltonen (he references a companion 50-page write-up and mentioned a
dedicated future-looking post on this specific idea) or other API-design voices (Vulkan Advisory
Panel members, DXVK/Mesa contributors) signalling vendor appetite has changed.
Re-check checklist
- Khronos Vulkan roadmap / provisional extensions — any generic-kernel-spawn proposal?
- DirectX Shader Model roadmap / DirectX Developer Blog — any entry-point-type unification?
- GDC/SIGGRAPH talks from NVIDIA/AMD/Intel/Apple architects on command-processor generality.
- Aaltonen's own blog/talks for the promised future-looking follow-up post.
Honesty note, unlike #688: there's no version-number-shaped signal to check here (no "MSVC
ships flag X"). This is closer to "has the industry conversation moved" than "has a toolchain
shipped" — re-checks will likely be judgment calls on talks/blog posts rather than a status table
flip. That's fine; the point is a scheduled nudge to look, not a precise gate.
Related: #691 (the achievable half of this design space).
What this tracks
Whether GPU hardware and vendor shading-language APIs have converged enough to support one
generic shader "kernel" type with intrinsics — texture sampling, ray queries, wave ops,
tensor/cooperative-matrix ops, and meshlet spawning all as callable intrinsics from any shader —
instead of today's ~16 separate shader-stage entry points (vertex / pixel / compute / mesh / task /
ray-gen / closest-hit / any-hit / miss / callable / intersection / amplification / ...).
This is the closing, explicitly speculative idea from Sebastian Aaltonen's Reducing Graphics API
Complexity talk (youtube.com/watch?v=aQv9pUl9PBM), discussed alongside #691 on 2026-08-08. It is
not part of #691's phased Vulkan roadmap — that roadmap (see ADR 0010/0011, especially the
root-data-as-pointer and thin-PSO decisions added in §4/§5) targets what's achievable on
current-generation hardware. This issue exists so we notice if that changes, the same way #688
watches C++26 reflection toolchain support rather than trying to build against it early.
Why this isn't picked up now
Per the talk itself, this needs hardware/command-processor microcode changes across vendors, not
just new API surface. The building blocks that exist today are real steps toward it, but the core
mechanism — spawn an arbitrary wave/kernel from any shader stage with a single GPU-pointer
argument, kick meshlets directly to the rasterizer from arbitrary compute — has no public vendor
timeline as of 2026-08.
What's already landed (partial progress toward this)
RayQuery/rayQueryEXT, Vulkan RT 1.1 / DXR 1.1) — callable from anyshader stage without a dedicated ray-generation shader. The clearest precedent for "intrinsic,
not a new shader type."
(SM6.x wave ops, Vulkan subgroup ops).
separate DirectML-shaped API (
VK_KHR_cooperative_matrix, SM6.8 wave-matrix).separate entry-point pair, not a general "kick from anywhere" mechanism.
Watch for / triggers to reopen this as real, scoped work
arbitrary shader stages, taking a single opaque-pointer argument.
task → mesh pipeline.
command-processor support for this.
dedicated future-looking post on this specific idea) or other API-design voices (Vulkan Advisory
Panel members, DXVK/Mesa contributors) signalling vendor appetite has changed.
Re-check checklist
Honesty note, unlike #688: there's no version-number-shaped signal to check here (no "MSVC
ships flag X"). This is closer to "has the industry conversation moved" than "has a toolchain
shipped" — re-checks will likely be judgment calls on talks/blog posts rather than a status table
flip. That's fine; the point is a scheduled nudge to look, not a precise gate.
Related: #691 (the achievable half of this design space).