u/thekhronosgroup

"Unlock the GPU as a general-purpose engine, not just a rasterizer."

This series takes you past `vkCmdDispatch` and into how compute actually executes on real hardware — occupancy, latency hiding, the Vulkan memory model, and subgroup operations that let invocations talk to each other without touching global memory.

* Vulkan 1.4 scalar layouts, shared memory (LDS), and memory consistency deep-dives

* Subgroup partitioning and non-uniform indexing — the "hidden power" most tutorials skip

* Run OpenCL kernels on top of Vulkan for a heterogeneous compute ecosystem

* Indirect dispatch, GPU-driven pipelines, and async compute orchestration

* Cooperative matrices, performance auditing, and AI-assisted compute diagnostics

* Dedicated coverage of mobile and embedded compute constraints

https://docs.vulkan.org/tutorial/latest/Advanced_Vulkan_Compute/introduction.html

Khronos will host a WebGL+WebGPU BOF at SIGGRAPH 2026 in Los Angeles on Wednesday, July 22 at 9:00 AM. (Full schedule coming soon.) Do you have a product or demo based on these APIs that you would like to share? If so, please email events@khronosgroup.org and we'll get you on the agenda.

Khronos Group's Vulkan Working Group has published a new sample demonstrating Shader Execution Reordering (SER) via the VK_EXT_ray_tracing_invocation_reorder extension.

Ray tracing workloads suffer when adjacent rays hit different materials, invoking different shaders and scattering memory access across geometry, textures, and acceleration structures. SER tackles this head-on by separating ray traversal from shader invocation, giving the GPU an opportunity to reorder threads for better coherency before execution begins.

The new sample features an interactive scene with three material types (diffuse, refraction, and emissive) specifically designed to maximize divergence, with a live toggle to compare SER on vs. off. Real-world path tracing workloads have seen 11-24% gains, with synthetic high-divergence scenarios showing 40-50% improvement.

Key topics covered in the sample:

• Hit objects and the reorderThreadEXT() / ReorderThread() pattern
• Coherence hints to guide reordering by material or instance
• Minimizing live state across reorder calls for maximum benefit
• Device capability detection and backward compatibility

Shaders are authored in Slang by default (GLSL reference files included), compiling to SPIR-V via the Slang compiler.

Explore the sample: https://github.com/KhronosGroup/Vulkan-Samples/tree/main/samples/extensions/ray_tracing_invocation_reorder

This sample demonstrates VK_EXT_rasterization_order_attachment_access, which enables framebuffer attachment reads from one fragment to the next in rasterization order, without requiring explicit synchronization or subpass self-dependencies. Techniques like programmable blending become far more practical.

The sample pairs the extension with VK_KHR_dynamic_rendering and VK_KHR_dynamic_rendering_local_read to show how to implement framebuffer fetch with guaranteed fragment ordering using modern Vulkan patterns.

Explore the sample: https://github.com/KhronosGroup/Vulkan-Samples/tree/main/samples/extensions/rasterization_order_attachment_access

Are you optimizing Vulkan applications for mobile or tile-based GPUs? The Vulkan Guide has a dedicated section on Tile Based Rendering (TBR) best practices worth bookmarking.

Unlike traditional immediate-mode GPUs, tile-based architectures process the framebuffer in small screen regions, keeping work on fast on-chip memory before writing results to main system memory. For Vulkan developers, this means memory bandwidth is often the dominant performance factor.

Key takeaways from the guide:

• Use load/store ops intentionally. Render pass attachment configuration is your primary tool for controlling bandwidth. Setting the right loadOp and storeOp values tells the driver whether to clear, load, or discard data, directly impacting whether data has to travel off-chip.
• Keep depth and stencil transient. If depth and stencil buffers are not needed after a render pass, mark them with LOAD_OP_CLEAR and STORE_OP_DONT_CARE. This allows the driver to keep them entirely on-chip and avoid the cost of writing them back to external memory.
• Favor compact pixel formats. On-chip tile memory is fixed in size. Smaller bit-depth formats allow the hardware to fit more data per tile, reducing spills to external memory and improving efficiency.
• Optimize for the binning pass. Tilers process geometry twice: once to bin triangles into tiles, then again to shade pixels. Separating vertex positions from other attributes like UVs and normals lets the GPU read only what it needs during binning, cutting unnecessary bandwidth.
• Provide clear intent to the driver. Because Vulkan abstracts hardware details like tile size, the best way to optimize is to use correct render pass configurations and memory flags so the driver can make informed decisions on your behalf.

The full guide covers these topics in depth, including guidance on MSAA, transient attachments, and dynamic rendering:

https://docs.vulkan.org/guide/latest/tile_based_rendering_best_practices.html