Computer Graphics

Cross posted from https://kbin.earth/m/gpu@programming.dev/t/2363483

Can we use WebGPU to compute real-time global illumination with surface patches called surfels? Does it look good enough? Is it fast enough? And can we finally construct viable compute-heavy rendering pipelines right here on the open web? Join me on this journey and let's find out!

The Khronos Vulkan API is in continuous development, and today the Vulkan Working Group has released two important updates to the API and ecosystem: an entirely new Descriptor system and the Vulkan Roadmap 2026 Milestone.

These new features and more will be discussed at the forthcoming Vulkanised 2026 conference, taking place in San Diego on February 9-11.

Initial support for these features is expected in the next Vulkan SDK release planned for Q1 2026.

Descriptor Heaps: The new VK_EXT_descriptor_heap extension represents a complete overhaul of the current Vulkan descriptor system, providing direct access to descriptor memory while preserving compatibility with legacy descriptor sets and other APIs. This extension is intended to completely replace Vulkan’s existing descriptor set mechanism, and the working group is actively seeking developer feedback before finalizing the API as a KHR extension targeting a future Vulkan Roadmap milestone.

Vulkan Roadmap 2026 Milestone: The latest roadmap milestone marks a significant increase in required functionality for high-end implementations beyond Vulkan 1.4 and previous milestones - requiring several long-standing optional features that developers have requested and raising a number of limits, including required support for:

• Variable rate shading
• Shader clock queries
• Host image copies
• Compute shader derivatives
• Various swapchain improvements
• Higher descriptor and shader interface limits

Most Vulkan adopters supporting the Vulkan 2026 milestone will offer conforming devices by the end of this year.

See the Vulkan Roadmap 2026 Milestone for full details.

This repository and the accompanying tutorial demonstrate ways of writing a Vulkan graphics application in 2026. The goal is to leverage modern features to simplify Vulkan usage and, while doing so, create something more than just a basic colored triangle.

Vulkan was released almost 10 years ago, and a lot has changed. Version 1.0 had to make many concessions to support a broad range of GPUs across desktop and mobile. Some of the initial concepts like render passes turned out to be not so optimal, and have been replaced by alternatives. The API matured and new areas like raytracing, video acceleration and machine learning were added. Just as important as the API is the ecosystem, which also changed a lot, giving us new options for writing shaders in languages different than GLSL and tools to help with Vulkan.

And so for this tutorial we will be using Vulkan 1.3 as a baseline. This gives us access to several features that make Vulkan easier to use while still supporting a wide range of GPUs and platforms.

One of the more unexpected talks at last week's Ubuntu Summit 25.10 in London was by Antonio Salvemini of Bolt Graphics, who introduced the company's forthcoming range of Zeus graphics accelerator hardware. These are very unlike any conventional GPUs – or indeed anything else.

[…]

Bolt's Zeus hardware will use an entirely different model, and we found it refreshing that the company's How it works page doesn't mention the dreaded initialism "AI" once. These accelerators are aimed at producing graphics using a specific rendering method called path tracing.

[…] Path tracing is a step further on from simple ray tracing. A few decades ago, ray tracing was a favorite way to demonstrate high-resolution, multi-color computer graphics, taking hours to days to render scenes of shiny spheres.

As Salvemini put it: "The problem with ray tracing is that each light wave only bounces one way. In path tracing, they can bounce anywhere, and you randomly select just some of these paths to display." Thus, Monte Carlo path tracing (MCPT) – as described in this 2024 UCSD computer graphics lecture [PDF] – uses Monte Carlo simulation, as invented by John von Neumann and Stanislaw Ulam during World War II.

There’s no shortage of examples of beginners rendering a simple triangle (or a cube), and with the new APIs having completely displaced the oxygen of older APIs, there is a certain expectation of ridiculous complexity and raw grit required to tickle some pixels on the display. 1000 lines of code, two weeks of grinding, debugging black screens etc, etc. Something is obviously wrong here, and it’s not going to get easier.

I would argue that trying to hammer through the brick wall of graphics is the wrong approach in 2025. Graphics itself is less and less relevant for any hopeful new GPU programmer. Notice I wrote “GPU programmer”, not graphics programmer, because most interesting work these days happens with compute shaders, not traditional “graphics” rendering.

Instead, I would argue we should start teaching compute with a debugger/profiler first mindset, building up the understanding of how GPUs execute code, and eventually introduce the fixed-function rasterization pipeline as a specialization once all the fundamentals are already in place. The raster pipeline was simple enough to teach 20 years ago, but those days are long gone, and unless you plan to hack on pre-historic games as a hobby project, it’s an extremely large API surface to learn.

In this series, we enhance a Vulkan renderer with ray tracing features to implement real-time pixel-perfect shadows (with and without transparency) and a bonus reflection effect. You will work with provided scaffolded code (based on the Vulkan Tutorial) and fill in key shader functions following step-by-step instructions.

Slides available here.

By the end, you’ll learn how to:

• Use Vulkan dynamic rendering (no pre-defined render passes) and verify it with RenderDoc.
• Create bottom-level and top-level Acceleration Structures (BLAS and TLAS) for ray tracing.
• Implement ray query based shadow rays (first with all-opaque geometry, then with alpha-test transparency).
• Debug/inspect the acceleration structures in Nsight Graphics.
• (Bonus) Implement ray query based reflections.

Prerequisites: This series targets intermediate Vulkan programmers. We assume you have completed the basic Vulkan Tutorial (graphics pipeline, descriptor sets, etc.). If not, you can still follow along conceptually. A Windows machine with up-to-date Vulkan SDK (1.4.311), a GPU supporting ray tracing (Vulkan Ray Query), plus RenderDoc and Nsight Graphics is provided.

Vcc - the Vulkan Clang Compiler, is a proof-of-concept C and C++ compiler for Vulkan leveraging Clang as a front-end, and Shady our own research IR and compiler. Unlike other shading languages, Vcc aims to stick closely to standard C/C++ languages and merely adds a few new intrinsics to cover GPU features. Vcc is similar to CUDA or Metal in this regard, and aims to bring the advantages of standard host languages to Vulkan shaders.

Key Features

Vcc supports advanced C/C++ features usually left out of shading languages such as HLSL or GLSL, in particular raising the bar when it comes to pointer support and control-flow:

• Unrestricted pointers
  • Arithmetic is legal, they can be bitcasted to and from integers
• Generic pointers
  • Generic pointers do not have an address space in their type, rather they carry the address space as a tag in the upper bits.
• True function calls
  • Including recursion, a stack is implemented to handle this in the general case
• Function pointers
  • Lets you write code in a functional style on the GPU without limitations
• Arbitrary goto statements - code does not need to be strictly structured !

Many of these capabilities are present in compute APIs, but are not supported in most graphics APIs such as DirectX or Vulkan. We aim to address this gap by proving these features can and should be implemented. More on why we think that’s important.