Latest blog posts

  • Rabbit holes in shader linking

    In the previous post I gave an introduction to shader linking. Mike has already blogged about this topic a while ago, focusing mostly on Zink, and now it’s time for me to share some of my adventures about it too, but of course focusing on how we improved it in RADV and the various rabbit holes that this work has lead me to.

  • What is shader linking?

    Shader linking is one of the more complicated topics in graphics driver development. It is both a never ending effort in the pursuit of performance and a black hole in which driver developers disappear. In this post, I intend to give an introduction to what shader linking is and why it’s worth spending our time working on it in general.

  • AMD RDNA3 mesh shading with RADV

    This is a long-awaited update to the previous mesh shading related posts. RDNA3 brings many interesting improvements to the hardware which simplify how mesh shaders work.

  • Mesh shaders arrive on your Linux computers

    September 1 was a big day! The official cross-vendor Vulkan mesh shading extension that I teased a while ago, has now been officially released. This is a significant moment for me because I’ve spent considerable time making the RADV implementation and collaborated with some excellent people to help shape this extension in Khronos.

  • What is NGG and shader culling on AMD RDNA GPUs?

    NGG (Next Generation Geometry) is the technology that is responsible for any vertex and geometry processing in AMD RDNA GPUs. I decided to do a write-up about my experience implementing it in RADV, which is the Vulkan driver used by many Linux systems, including the Steam Deck. I will also talk about shader culling on RDNA GPUs.

  • Task shader driver implementation on AMD HW

    Previously, I gave you an introduction to mesh/task shaders and wrote up some details about how mesh shaders are implemented in the driver. But I left out the important details of how task shaders (aka. amplification shaders) work in the driver. In this post, I aim to give you some details about how task shaders work under the hood. Like before, this is based on my experience implementing task shaders in RADV and all details are already public information.

  • How mesh shaders are implemented in an AMD driver

    In the previous post I gave a brief introduction on what mesh and task shaders are from the perspective of application developers. Now it’s time to dive deeper and talk about how mesh shaders are implemented in a Vulkan driver on AMD HW. Note that everything I discuss here is based on my experience and understanding as I was working on mesh shader support in RADV and is already available as public information in open source driver code. The goal of this blog post is to elaborate on how mesh shaders are implemented on the NGG hardware in AMD RDNA2 GPUs, and to show how these details affect shader performance. Hopefully, this helps the reader better understand how the concepts in the API are translated to the HW and what pitfalls to avoid to get good perf.

  • Mesh and task shaders intro and basics

    Mesh and task shaders (amplification shaders in D3D jargon) are a new way to process geometry in 3D applications. First proposed by NVidia in 2018 and initially available in the “Turing” series, they are now supported on RDNA2 GPUs and are part of the D3D12 API. There is also an extension in Vulkan (and a vendor-specific one in OpenGL). This post is about what mesh shadig is and next time I’m going to talk about how mesh/task shaders are implemented on the driver side.

  • Welcome to my blog!

    I’ve wanted to do this for a long time, but somehow never got around to it. The main inspiration for this blog are the blogs of my colleagues Mike, Bas and Martin who are all writing exciting stuff about their work.

subscribe via RSS