Shader Slang

Shading Languages Symposium

Fri, 17 Oct 2025 08:00:00 +0000

Shading Language Symposium

This ground-breaking Shading Language Symposium brings together shading language implementors, developers, researchers and technical artists to explore the future of shading languages and real-time rendering technologies.

The symposium will focus on the evolving landscape of shading languages and the emerging technologies that are shaping the next generation of graphics programming.

If you work with Shading Languages then this event will provide a unique opportunity to connect with your peers, learn from leaders in their fields, and advance your expertise.

The Symposium is organised by the Khronos Group and will take place immediately after Vulkanised 2026. We value a diversity of voices, perspectives and experiences and are dedicated to providing a harassment-free experience for everyone.

Learn More

SIGGRAPH 2025 Materials Now Available: Recordings and Resources from Our Events

Mon, 06 Oct 2025 17:00:00 +0000

Recordings and materials from all three of our SIGGRAPH 2025 sessions are now available! Whether you missed the events or want to revisit the content, you can now access everything from our hands-on lab, Birds of a Feather session, and neural shading course.

Hands-On Class: Introduction to Slang

Our hands-on lab covered everything from language fundamentals to advanced features like modules, generics, and automatic differentiation. You can now see the recording, or work through the entire session at your own pace.

Download the lab materials and walk through the examples on your own computer here:
Lab Materials
Lab Slides

And view the recording here:
Lab Recording

Birds of a Feather: Developing with Slang

Our Birds of a Feather session covered the latest developments, language roadmap, and featured discussions with developers using Slang in production.

Presentation Materials
Recording

Neural Shading Course

Our intensive course on neural shading techniques provides a deep dive into the cutting edge of graphics programming, showing how to implement neural networks in Slang while leveraging automatic differentiation and modern GPU capabilities.

You can find the slides for this course, along with all example code in our repository, or watch the recordings:

Neural Shading Course Materials
Course Recordings

These materials provide comprehensive coverage of modern shader programming with Slang, from basic concepts to advanced techniques. Whether you’re new to Slang or looking to expand your skills, these resources offer valuable insights into the future of shader development.

Getting Started with Slang: Automatic Differentiation

Mon, 06 Oct 2025 08:00:00 +0000

Getting Started with Slang: Automatic Differentiation

Mon, 06 Oct 2025 08:00:00 +0000

Presentations

Powerpoint Slides - Getting Started with Shader Slang Autodiff (pdf)

Automatic Differentiation

Join us for a focused deep dive on automatic differentiation in Slang with Shannon Woods. This session distills the core concepts of autodiff, emphasizing how forward and reverse modes work, how gradients propagate, and how to reason about correctness and efficiency with clear, minimal examples.

What we’ll cover:

Forward and backward gradient propagation: intuition and step‑by‑step examples
How to invoke autodiff from Slang
Diff pairs and the forward/backward operators
Differentiable vs. non‑differentiable types; making custom structs differentiable
Providing custom derivatives for fine‑grained control
Handling buffer access and gradient accumulation patterns
Practical techniques for debugging and validating gradients

Who should attend:

Graphics engineers exploring optimization or inverse problems
Researchers and practitioners in differentiable rendering or neural graphics
Developers curious about practical, GPU‑friendly autodiff concepts
Bring your questions—there will be time for discussion and hands‑on gradient debugging tips.

Graphics Programming Conference 2025

Fri, 12 Sep 2025 08:00:00 +0000

Location: Breda, The Netherlands
Website: https://graphicsprogrammingconference.com/

In its second year, Graphics Programming Conference will have the latest advances in real-time rendering in games, interactive applications and other new developments.

Wednesday, November 19th at 16:00

Slang Working Group Chair, Shannon Woods, will lead a session on Slang, the open-source, cross-platform shading language hosted by the Khronos Group. This presentation will explore how Slang’s modern features enable neural graphics techniques across diverse GPU platforms. We will examine Slang’s key architectural advantages: its modular system for scalable shader development, built-in automatic differentiation capabilities, and seamless cross-platform compilation. We will explore Slang’s automatic differentiation system, enabling gradient-based optimization without requiring external ML frameworks. By understanding Slang’s language design and capabilities, graphics programmers can leverage its neural graphics features to build more sophisticated and performant shader systems, unlocking new possibilities in real-time rendering across all target platforms.

View the GPC2025 Website

Getting Started with Slang: Modularization

Tue, 09 Sep 2025 08:00:00 +0000

Slang at SIGGRAPH 2025

Fri, 08 Aug 2025 17:00:00 +0000

We’re excited to announce that Slang will have a significant presence at SIGGRAPH 2025 in Vancouver this August! This year’s conference will feature three major Slang events: a hands-on lab for learning the language, a comprehensive course on neural shading techniques, and a Birds of a Feather session for community discussion and updates.

Hands-On Class: Introduction to Slang

Sunday, August 10, 4:00-5:30 PM PDT
West Building, Rooms 121-122

Join us for a comprehensive hands-on lab that will take you from Slang basics to advanced features. This interactive session, led by NVIDIA’s Nia Bickford, Tristan Lorach, and Chris Hebert, will cover:

Language Fundamentals: Modern shader programming constructs and syntax
Advanced Features: Modules, generics, and interfaces for scalable code organization
SlangPy Integration: Python-based development and rapid prototyping
Automatic Differentiation: Neural graphics and machine learning capabilities
Cross-Platform Development: Writing shaders that work across multiple GPU APIs

The lab is designed for graphics developers of all experience levels, from those new to shader programming to experienced developers looking to modernize their workflow. Computers will be provided, so no preparation is required—just bring your curiosity and enthusiasm for modern shader development!

Birds of a Feather: Developing with Slang

Wednesday, August 13, 2:30-3:30 PM PDT
British Ballroom, Fairmont Waterfront

This community-focused session will provide the latest updates on Slang development and foster discussions about the future of shader programming. The session will include:

Community Update: Latest developments and ecosystem growth
Language Roadmap: Upcoming features and development priorities
Industry Perspectives: Real-world experiences from companies using Slang
Open Discussion: Q&A and community feedback

This is your opportunity to connect with the Slang Working Group, share your experiences, and help shape the future direction of the language. Whether you’re actively using Slang or just curious about modern shader development, this session will provide valuable insights and networking opportunities.

An Introduction to Neural Shading

Thursday, August 14, 9:00 AM-12:15 PM PDT
West Building, Rooms 109-110

This intensive course will teach you how to implement neural shading techniques using Slang, where traditional graphics algorithms are replaced with neural networks. This course covers:

Neural Shading Fundamentals: Theory and practical implementation of neural networks in graphics
Automatic Differentiation: Deep dive into Slang’s autodiff capabilities for gradient-based optimization
MLP Implementation: How to build and optimize Multi-Layer Perceptrons in Slang
Hardware Acceleration: Leveraging modern GPU tensor cores and cooperative vectors
Production Deployment: Real-world considerations for shipping neural shading techniques

The course includes interactive samples written in Python and Slang, allowing you to follow along and experiment with the techniques in real-time. This is your opportunity to learn from the experts who are pushing the boundaries of what’s possible with neural graphics.

Latest Slang Release

We’re also excited to announce our latest Slang release, which brings significant improvements and new features to the language. This release continues our commitment to making shader programming more accessible and powerful: Slang Release v2025.14.3

We’re also excited to announce our latest Slang release, which brings significant improvements and new features to the language, including:

Language Enhancements and New Functionality

Support for default implementations in interface methods
New override keyword requirement for overriding default interface methods
Added control arguments for floating-point denormal mode
Extended expand operator support for concrete tuple values

Compiler Architecture Improvements

We’ve redesigned how AST deserialization and deduplication is implemented in the compiler, enabling on-demand deserialization of the core module. This architectural improvement leads to a significant performance boost, with over 3x speedup in createGlobalSession and reduced end-to-end compile times for small to medium shaders. In our benchmarks, the compile time for a typical fragment shader with slangc dropped from 260ms to 80ms.

Improvements to Code Generation, Debugging, and Platform Support.

Added support for SPV_EXT_fragment_invocation_density (SPV_NV_shading_rate)
Implemented GLSL/SPIR-V built-in variable DeviceIndex
Added MSVC-style bitfield packing
Improved matrix type handling:
- Automatic lowering of unsupported matrix types for GLSL/WGSL/Metal targets
- Conversion of int/uint/bool matrices to arrays for SPIR-V
Enhanced reflection API with combined texture-sampler flag to differentiate Texture2D from Sampler2D
Added mad operation support in WGSL
Improved debugging capabilities:
- Added DebugGlobalVariable instructions to SPIR-V output
- Updated to 1-based argument indexing for DebugLocalVariable

Language Server Improvements

Auto-sort completion suggestions by relevance and context
Show function signature assistance when working with generic types and functions
Intelligent auto-completion when implementing interface methods with override keyword

Apart from these changes, we also landed many smaller fixes that improve the compiler’s performance, stability and consistency.

This release demonstrates our ongoing investment in Slang’s capabilities and our commitment to the graphics development community. Whether you’re working on traditional rendering pipelines or exploring neural graphics techniques, these new features will help you write better, more maintainable shader code.

Can’t Make It to SIGGRAPH?

If you can’t attend SIGGRAPH 2025 in person, you can still stay connected with the Slang community:

Try Slang Online: Experiment with Slang in your browser
Join the Community: Connect with other developers on our Discord server
Explore Examples: Check out our GitHub repository for tutorials and sample code
Follow Updates: Stay informed about Slang developments through our blog and social media

Looking Forward

SIGGRAPH 2025 marks an exciting milestone for Slang as we continue to build a modern, accessible shader programming ecosystem. Whether you’re attending the hands-on lab, the neural shading course, the Birds of a Feather session, or all three, we’re looking forward to meeting you and sharing the latest developments in shader language technology.

See you in Vancouver!

For more information about SIGGRAPH 2025, visit the official conference website.

Slang: Using AI coding assistants

Fri, 01 Aug 2025 00:00:00 +0000

Introduction

Large Language Models(LLMs) aid coding by boosting productivity. llms.txt is a proposed standard for websites to offer LLM-friendly content, mainly to assist LLMs during inference. Slang now supports the llms.txt standard. You can now use LLMs to accelerate your development with help of coding assistants like Cursor or any tool of choice by providing relevant context about Slang’s documentation, within your projects. We provide 3 different versions of llms.txt:

llms.txt - contains links with brief descriptions for agents to navigate. Use this if you’re looking for basic understanding of Slang
llms-full.txt - contains entire Slang docs compressed into the llms.txt format. Use this for more detailed documentation or for detailed explanations of Slang.
llms-SlangPy-full.txt - contains SlangPy related information. Use this for SlangPy related topics.

Usage

You can download these and use them with Cursor, or simply include them as part of the context to get started.The SlangPy version of the file is maintained separately due to its distinct repository and focus on Python interfaces. These files are available for download and can be integrated with Cursor, or alternatively, included as contextual resources to facilitate initial setup. Integrating llms-full.txt directly into the prompt significantly enhances the quality of the output.

Below is an illustration of utilizing llms.txt within Cursor for the development of a Slang-based application. This demonstrates how users can access high-quality documentation concerning generics and gain insight into their implementation. Here we can see the following happen:

User provides the llms-full.txt as part of the prompt and posts a query related to how they can use Slang features
We can see that the LLM goes through the relevant documentation and obtains answers as to how generics and interfaces can help reduce code duplication.
The LLM then goes ahead and provides implementation as well on how this can be done.
Note: Given the current state of LLMs, output may not be 100% accurate, compilable code, so you will need to review it closely.

Your browser does not support the video tag.

We encourage you to try out this integration and experience firsthand how it can streamline your development workflow, and we welcome your feedback to help us further improve this valuable tool. Kindly start discussion on our Slang Discord or file issues on our GitHub if you have suggestions.

Getting Started with Slang: Modularization

Mon, 28 Jul 2025 08:00:00 +0000

Tired of wrestling with preprocessor macros and copy-pasting shader code? Discover how Slang’s modern module system can revolutionize your shader development workflow!

Join us for an introductory talk where we’ll explore:

Modules & Visibility Control

Learn how to organize your shader code into clean, reusable modules with proper access control (public, internal, private) that actually makes sense.

Compilation Pipeline Magic

See how modules enable separate compilation, and how that translates to faster compile times when you need to compile many different shader variants specialized from the same source code.

Specialization Without Preprocessor Pain

Discover how Slang’s language features let you specialize shaders at link-time without the mess of #ifdef spaghetti. Write cleaner, more maintainable code that works synergistically with modules and separate compilation.

Generics vs Templates: The Slang Way

Understand the difference between Slang’s type-safe generics and C++ templates, and why Slang generics is the key to allow true separate compilation.

Whether you’re building a rendering engine or just want to write better shaders, this talk will show you how Slang modules can make your code more modular, faster to compile, and easier to maintain. Perfect for developers looking to move beyond traditional HLSL workflows!

Prerequisites

No prior Slang experience required - we’ll start from the basics and build up to practical examples you can use immediately.

Speaker

Yong He, NVIDIA

The Khronos Group is dedicated to providing a harassment-free conference experience for everyone. Visit our Code of Conduct page to learn more.

Neural Graphics: Speeding It Up with Wave Intrinsics

Thu, 17 Jul 2025 00:00:00 +0000

In our journey through neural graphics, we started with Neural Graphics in an Afternoon, exploring the exciting possibilities of representing and rendering scenes with machine learning approaches. We then delved into Neural Graphics: First Principles to Performance, laying down some initial strategies for making these techniques practical. Now, we’re ready to roll up our sleeves and explore more advanced performance optimizations, using our familiar 2D differentiable Gaussian splatting example as a testbed.

Let’s look at the modifications added to a new example in the SlangPy samples repository, balloted-splatting. This example starts with the same Python code as its predecessor, diff-splatting, which we walked through in our previous blog post.

Recapping the 2D Differentiable Gaussian Splatting Example

As a quick refresher, these examples implement a 2D Gaussian splatting algorithm. We represent a scene (or in this case, a 2D image) with a collection of 2D Gaussian “blobs,” each defined by parameters like center, covariance (shape/rotation), and color. We then render an image by splatting these Gaussians onto a canvas, and Slang’s automatic differentiation capabilities allow us to compute how the loss function (the difference between our rendered image and a target) changes with respect to each Gaussian’s parameters. This enables us to train the Gaussians to reconstruct a target image.

The Python script (main.py) driving this process is nearly identical between the two examples, with one key difference: the balloted-splatting example uses SlangPy’s ability to set a specific call group shape to explicitly match the wavefront size. For example, when kicking off the backward propagation of our loss calculation, we now call

module.perPixelLoss.call_group_shape(Shape((WORKGROUP_X, WORKGROUP_Y))).bwds(per_pixel_loss, dispatch_ids, blobs, input_image)

This code uses the WORKGROUP_X and WORKGROUP_Y values to define the dispatch shape according to the available workgroup dimensions. We’ll be using wave intrinsics, which allow different threads within a single subgroup to share certain information and do calculations collaboratively, so we want to ensure that the work is organized into appropriately sized groups for our hardware to process. In general, the goal is to saturate all the available threads with work, so that none of the compute units are left idle.

The number of threads available in a single subgroup can vary from one hardware architecture to another; for ease of explanation, this example uses a set of compile-time constants to define its dispatch size, and assumes only one subgroup per workgroup. If you wished to deploy code like this to different systems with different GPUs, you’d need to do some additional work to determine the correct dimensions at runtime. Additionally, using only a single subgroup for each workgroup has potential downsides: this code will be vulnerable to stalls where there are operations like memory reads which introduce latency. If multiple subgroups are being processed, GPUs are able to swap between them to make efficient use of their available cycles while waiting on operations to complete. For now, when running this example, you’ll want to take a moment to ensure that WORKGROUP_X and WORKGROUP_Y are set to values that, when multiplied together, give the subgroup size for your hardware. (On NVIDIA and AMD RDNA systems, this value is 32.)

That said, most of the difference between the previous example and this one shows up in the Slang shader code itself (diffsplatting2d.slang vs. ballotsplatting2d.slang), specifically in how Gaussians are culled, sorted (or not), and rasterized.

The `diff-splatting` Approach: A Straightforward Staged Pipeline

The diff-splatting example implements the rendering for each tile (a small patch of pixels processed by a GPU workgroup) through a multi-stage process within its main splatBlobs Slang function:

Coarse Rasterization (coarseRasterize): This initial stage identifies which Gaussians potentially affect the current tile. Indices of intersecting Gaussians are stored in groupshared memory, using an Atomic\<uint\> (blobCountAT) to safely manage concurrent writes from multiple threads.
Padding (padBuffer): The shared list of blob indices is then padded.
Sorting (bitonicSort): A workgroup-level bitonic sort arranges the intersecting blob indices. This sorting ensures Gaussians are composited in the right order.
Fine Rasterization (fineRasterize): With a sorted list of relevant Gaussians, each pixel within the tile iterates through them. It evaluates each Gaussian’s contribution and blends it with the pixel’s current color. This function also has an associated custom backward pass (fineRasterize\_bwd) for the differentiation process, which “undoes” the blending operations to propagate gradients.

This staged pipeline is logical and relatively straightforward to follow. However, explicit multi-stage processing involving groupshared memory and a full sort can introduce performance overhead and synchronization points.

`balloted-splatting`: Harnessing GPU Wave Intrinsics

The balloted-splatting example presents a more sophisticated and often more performant approach by leveraging wave intrinsics (also known as subgroup operations in Vulkan, or shuffle operations in CUDA). These are GPU hardware commands allowing threads within a small, fixed-size group (a “wave” or “subgroup,” typically 32 or 64 threads) to communicate and coordinate with very high efficiency.

You can see this in action in the new cullAndApplyBlobs function, which effectively replaces the coarseRasterize, padBuffer, bitonicSort, and fineRasterize sequence from the previous example.

/*
 * cullAndApplyBlobs finds blobs which intersect the current tile and evaluates them in a single pass using
 * wave intrinsics.
 *
 * This uses the multiplicative alpha blending algorithm laid out in the original GS paper (https://repo-sam.inria.fr/fungraph/3d-gaussian-splatting/)
 * This is represented as a 'state transition' (transformPixelState) as we go through the blobs in order, so that we can
 * concisely represent the 'state undo' operation in the custom backwards pass (fineRasterize_bwd).
 *
 * In Slang, custom derivative functions can be defined using the `[BackwardDerivative(custom_fn)]` attribute.
 */
[BackwardDerivative(fineRasterize_bwd)]
float4 cullAndApplyBlobs(Blobs blobs, OBB tileBounds, uint localIdx, no_diff float2 uv)
{
    PixelState pixelState = PixelState(float4(0, 0, 0, 1), 0);
    uint numIntersectingBlobs = 0;
    
    // Traverse the list in workgroup-sized chunks. Each lane in the workgroup/wave will be responsible for
    // determining if one gaussian in the chunk intersects the current tile.
    for (uint wgStart = 0, numGaussians = Gaussian2D.count(blobs); wgStart < numGaussians; wgStart += WG_SIZE)
    {
        // lane 0 will load the blob represented at position wgStart, and other lanes will get the subsequent blobs
        Gaussian2D coarseBlob = Gaussian2D.load(blobs, wgStart + localIdx);
        bool intersects = coarseBlob.bounds().intersects(tileBounds);

        // All lanes write to the ballot bitmask to indicate whether intersection is true;
        // so all lanes will have the same value for intersectionMask
        uint intersectionMask = WaveActiveBallot(intersects).x;

        while(intersectionMask != 0)
        {
            // identify the next lane with intersects == true in this chunk
            uint idxInChunk = firstbitlow(intersectionMask);
            uint16_t blobIdx = wgStart + idxInChunk; // then get the index for that blob
         
            intersectionMask &= intersectionMask - 1; // remove the least significant 1 bit from the mask

            float4 blobEval = eval(blobs, blobIdx, uv);
            pixelState = transformPixelState(pixelState, blobEval, blobIdx);

            intersectingBlobList[min(numIntersectingBlobs++, GAUSSIANS_PER_BLOCK - 1)] = blobIdx;
        }

        // if ALL the blobs processed in this chunk are below the alpha threshold,
        // stop processing blobs.
        if (WaveActiveAllTrue(pixelState.value.a < 1.f / 255.f))
        {
            break;
        }
    }

    intersectingBlobCount = numIntersectingBlobs;
    maxCount[localIdx] = pixelState.finalCount;
    finalVal[localIdx] = pixelState.value;
    return pixelState.value;
}

One thing to note here is that wave intrinsics like WaveActiveBallot are not universally supported by all combinations of graphics hardware and API. Under the hood, Slang keeps track of what capabilities are required in order to use optional features, and it will provide a warning if you attempt to compile for a profile that can’t support the necessary capabilities. For example, if you were to compile this shader with ‘-profile sm_5_0’, you’d get this warning:

myshader.slang(9): warning 41012: entry point 'computeMain' uses additional capabilities that are not part of the specified profile 'sm_5_0'. The profile setting is automatically updated to include these capabilities: 'sm_6_0'  

So how does this shader use wave intrinsics?

Instead of a multi-pass approach– first identifying intersecting blobs for the current tile, sorting them, and then calculating colors from the shorter list of blobs, we’re now using a single pass through the set of Gaussians to process them all, in workgroup-sized chunks. Within each chunk, each lane (a thread within the wave) is assigned a single Gaussian, and tests whether it intersects the current tile bounds. The crucial improvement here is the WaveActiveBallot(intersects).x call. This takes the boolean intersection result from each active lane in the wave, and creates a bitmask. All of the lanes in the wave can access the bitmask, and can therefore understand which Gaussians in the chunk being processed are relevant. The code then iterates through the set bits of this mask, which we’ve called intersectionMask. For each intersection Gaussian, its contribution is evaluated, and immediately alpha-blended. We still store the indices for the intersecting blobs, because we will still need them during the custom backward pass.
One benefit of this approach is that we no longer need to do an explicit workgroup-wide sort. Because we keep the blobs in order during processing, we maintain the needed order for alpha blending. Additionally, we no longer need to use an atomic counter– and thereby introduce the possibility of contention– when we increment the number of intersecting blobs and write the index to the blob list. This might look problematic at first glance, because all of the lanes are writing to the same intersectingBlobList in shared memory. But we don’t need to worry about data collisions here because of how we’re coming up with this data. Each lane has its own copy of numIntersectingBlobs, so that variable does not need to be atomically incremented. And each lane also will be operating on the same value in intersectionMask, calculated using WaveActiveBallot. For this reason, all lanes are storing the same indices in the same order into intersectingBlobList, so while technically this is a data race, it’s a benign one.
We’ve also changed the type for a couple of our storage parameters: intersectingBlobList and maxCount have both been changed from uint to uint16, which reduces their memory footprint in groupshared memory. As we noted in the previous post, workgroup shared memory is very small. One potential side effect of requesting very large amounts of shared memory for a workgroup is that fewer workgroups can be scheduled simultaneously on a single unit. This is inefficient, because that means that a chunk of the available compute hardware will sit idle.

The Performance Payoff

Why undertake this refactoring? The shift to a wave intrinsic-based approach in balloted-splatting is squarely aimed at improving performance and efficiency:

Reduced Synchronization Overhead: Wave operations are generally tightly coupled with the hardware and can involve less synchronization overhead than operations requiring coordination across an entire workgroup using shared memory.
Eliminating the Bottleneck of Sorting: Explicitly sorting data in shared memory (like the bitonicSort) is computationally intensive and can be a significant performance bottleneck. The ballot-based approach sidesteps this.
Better Hardware Utilization: Wave intrinsics are designed to map directly onto efficient GPU hardware pathways, allowing for faster execution of tasks like voting (balloting), data exchanges (shuffling), and other coordinated operations within a subgroup.

This performance benefit is easily observable when running the diff-splatting and balloted-splatting examples side-by-side. On my Windows 11 system, equipped with an RTX 5090, the diff-splatting example takes 47 seconds to complete 10000 iterations, averaging 211 iterations per second. balloted-splatting completes the same number of iterations in 37 seconds, a 21% reduction in execution time, and averages 266.4 iterations per second. Similarly, on the integrated GPU, the execution time drops from around 1 hour 20 minutes for diff-splatting to 1 hour and 6 minutes for balloted-splatting.

Looking Ahead

The evolution from diff-splatting to balloted-splatting demonstrates how subgroup-specific techniques like WaveActiveBallot can provide significant performance benefits by reducing duplicate work, and allowing simultaneously executing threads to work collaboratively. That is, the same compute optimization techniques already available to traditional graphics can also be a great benefit to neural graphics approaches. The examples we’ve explored here are just the beginning—there’s a rich landscape of GPU-specific techniques waiting to be applied to neural rendering pipelines, and Slang provides a powerful foundation for exploring them.

Getting Started with Slang: Reflections API

Tue, 08 Jul 2025 08:00:00 +0000

Slang at HPG 2025: Bridging Graphics and Machine Learning with Automatic Differentiation

Mon, 16 Jun 2025 17:00:00 +0000

We’re excited to announce that Slang will be presented at High-Performance Graphics (HPG) 2025 in Copenhagen! Our presentation, part of the Hot 3D track, will demonstrate how Slang’s automatic differentiation capabilities are making neural graphics techniques more accessible to real-time graphics developers.

Why This Matters

Neural techniques like Gaussian splatting and learned materials are delivering unprecedented visual quality, but implementing them has traditionally meant juggling separate codebases in ML frameworks and graphics APIs. Slang changes this by bringing automatic differentiation directly to shader programming, enabling developers to implement gradient-based optimization without leaving their familiar graphics environment.

Join Us at HPG 2025

For the complete conference schedule, visit https://highperformancegraphics.org/2025/program/schedule/.

Can’t Make It?

Stay connected with Slang’s neural graphics developments:

Try our 2D Gaussian Splatting examples
Experiment with Slang in your browser
Join us on the Slang Discord

We’re looking forward to demonstrating how Slang is making neural graphics more accessible to everyone. See you at HPG 2025!

Getting Started with Slang: Reflections API

Wed, 04 Jun 2025 08:00:00 +0000

We know it: many developers that are just getting started with Slang find themselves daunted by the reflection API. During this meet-up we will explain the underlying mental model for how Slang reflects shader code and show specific code examples for how to use the reflection API to access the information that developers most often need. Along the way we will call out caveats and pitfalls that we’ve seen bite developers before.

Prerequisites

This will be a practical nuts-and-bolts presentation that assumes attendees already have experience with GPU shader programming and the Vulkan API. Prior experience with the Slang reflection API and the features of the Slang language will be beneficial but is not required

Speaker

Theresa Foley, NVIDIA

The Khronos Group is dedicated to providing a harassment-free conference experience for everyone. Visit our Code of Conduct page to learn more.

Getting Started with Slang: Draw Your First Splat

Tue, 20 May 2025 08:00:00 +0000

Getting Started with Slang: Draw Your First Splat

Wed, 30 Apr 2025 17:00:00 +0000

Join us for an engaging hands-on session where we’ll walk through creating your first Gaussian splat using Slang. Perfect for graphics programmers interested in getting started with neural techniques, this hands-on introduction will take you from installation through basic shader compilation to rendering your first splat.

We’ll cover everything you need to get started

Setting up Slang for development
Understanding the basics of Gaussian splats
Writing and compiling your first Slang shader

This beginner-friendly session includes step-by-step code examples and demonstrations, with time for Q&A. By the end, you’ll understand how to use Slang and be ready to explore the training process.

Prerequisites

Basic understanding of computer graphics concepts
Familiarity with shader or kernel programming languages (HLSL, GLSL, etc)
No prior Slang or Gaussian splatting experience required
Optional: Have Slang compiler installed if you want to follow along

Speakers

Shannon Woods, Slang Working Group Chair. NVIDIA.

The Khronos Group is dedicated to providing a harassment-free conference experience for everyone. Visit our Code of Conduct page to learn more.

Neural Graphics: From First Principles to Performance

Wed, 30 Apr 2025 17:00:00 +0000

In my last blog post, I gave an introduction to how gradient descent is used to drive gaussian splatting representations– essentially, going through a list of blobs in 2D space, calculating their color values at a specific texture coordinate, and blending them together, and iteratively adjusting them to be as close as possible to an ideal target image. Notably, this simplified version had significant performance and quality limitations. In this post, I’ll take you through the changes needed to go from that simple pedagogical example to an implementation that achieves real-time performance.

A More Efficient Algorithm

The key limitation of our previous implementation was that it evaluated every gaussian blob for every pixel. This is extremely inefficient since most gaussians only affect a small region of pixels. We can do much better by breaking this into three logical steps:

For each gaussian, determine which tiles of the image it will affect (coarse rasterization)
For each tile, sort its affecting gaussians back-to-front
For each pixel in the tile, accumulate the color contributions only from gaussians that affect that tile (fine rasterization)

While we could implement these as separate compute kernels, we can achieve better performance by combining them into a single kernel using workgroup-level collaboration between threads. Let’s look at how this works.

Tile-based Rasterization with Workgroups

The core optimization in our approach is to divide the image into tiles, where each tile is processed by a compute workgroup - a collection of threads that execute together and can share data efficiently. This allows us to:

Build a per-tile shortlist of only the gaussians that affect that tile
Sort just those gaussians that affect the tile
Process pixels within the tile using only the relevant gaussians

A workgroup is a collection of threads that execute simultaneously on the same compute unit. These threads can collaborate using special operations and share data quickly through a small amount of on-chip memory. We’ll use this capability to efficiently build and process our per-tile gaussian lists.

Here’s how the implementation works in Slang:

// ----- Constants and definitions --------

static const int GAUSSIANS_PER_BLOCK = 512;
static const int WG_X = 8;
static const int WG_Y = 4;

// -----------------------------------------

// Some types to hold state info on the 'blobs' buffer.
// This makes it easy to make sure we're not accidentally using the buffer
// in the wrong state.
//
// The actual data is in the 'blobs' object.
//
struct InitializedShortList { int _dummy = 0; };
struct FilledShortList { int _dummy = 0; };
struct PaddedShortList { int _dummy = 0; };
struct SortedShortList { int _dummy = 0; };

/*
 * coarseRasterize() calculates a subset of blobs that intersect with the current tile. Expects the blob counters to be reset before calling.
 *
 * The coarse rasterization step determines a subset of blobs that intersect with the tile.
 * Each thread in the workgroup takes a subset of blobs and uses bounding-box intersection tests to determine
 * if the tile associated with this workgroup overlaps with the blob's bounds.
 *
 * Note: This is a simplistic implementation, so there is a limit to the number of blobs in the short-list (NUM_GAUSSIANS_PER_BLOCK).
 * In practice, if the number of blobs per tile exceeds this, NUM_GAUSSIANS_PER_BLOCK must be increased manually.
 * A more sophisticated implementation would perform multiple passes to handle this case.
 *
 */
FilledShortList coarseRasterize(InitializedShortList sList, Blobs blobset, OBB tileBounds, uint localIdx)
{
    GroupMemoryBarrierWithGroupSync();

    Gaussian2D gaussian;
    uint numGaussians = Gaussian2D.count(blobset);
    for (uint i = localIdx; i < numGaussians; i += (WG_X * WG_Y))
    {
        gaussian = Gaussian2D.load(blobset, i, localIdx);
        OBB bounds = gaussian.bounds();
        if (bounds.intersects(tileBounds))
        {
            blobs[blobCountAT++] = i;
        }
    }

    GroupMemoryBarrierWithGroupSync();

    blobCount = blobCountAT.load();

    return { 0 };
}

Up at the top of this block, we define a few constants. WG_X and WG_Y describe the dimensions of our workgroup– we’re going to process blocks 8 pixels wide, and 4 pixels tall. These dimensions are chosen because most GPUs can execute 32 or 64 threads simultaneously. The maximum number of blobs we’ll add to the short list for each workgroup is set somewhat arbitrarily – we found 512 was a threshold that gave a good balance between performance and image quality.

You’ll also see that the coarseRasterize function takes an InitializedShortList parameter, but doesn’t appear to do anything with it. That’s because this implementation uses a set of sentinel struct types to enforce the correct ordering of the steps in the rasterization algorithm – essentially, this helps us catch bugs at compile time rather than runtime. It doesn’t affect how our gaussian splatting implementation works, so I won’t go deeper into it here.

Inside the function, the first thing that we do is to call GroupMemoryBarrierWithGroupSync. This is a memory barrier, which tells the GPU to wait here until all of the load and store operations being done by this workgroup on its shared memory have completed. This is important to avoid data races. The first barrier ensures that no threads start writing into the InitializedShortList parameter until the calling function has finished initializing it, while the barrier at the end of the function makes sure that all the threads have finished adding blobs to the list before the final count is retrieved with blobCount = blobCountAT.load();.

Then, we begin building our short list of relevant gaussian blobs. We want to split this work up across all of our workgroup threads, so that we can process the list of blobs efficiently and without duplicated work. The way we do this is that we ask each thread to start by accessing the blob in the global list that corresponds to its local thread index– an identifier that, similar to the texture coordinates we generated in the simpler example using SlangPy’s grid generator, allows each thread to understand where it sits within the workgroup. In this case, we’re using a 1-dimensional dispatch shape, and will need to do some math later to figure out what pixel we’re calculating within the image. I’ll explain that in more detail when we get there. Each thread will check its assigned first blob, and then skip ahead by the number of blobs that there are threads in the workgroup. So, with our WG_X (8) and WG_Y (4) describing a total thread group size of 32, we have threads examining blobs at that stride: Thread 0 checks blobs 0, 32, 64, … Thread 1 checks blobs 1, 33, 65, … And so on…

Whenever a blob is identified that intersects with the current tile, it’s added to the shortlist using this line:

        blobs[blobCountAT++] = i;

The shortlist blobs and its index incrementor blobCountAT didn’t appear in the excerpt above – that’s because they’re using workgroup shared memory, so they’re declared a bit differently, like this:

// ----- Shared memory declarations --------

// Note: In Slang, the 'groupshared' identifier is used to define
// workgroup-level shared memory. This is equivalent to '__shared__' in CUDA

// blobCountAT is used when storing blob IDs into the blobs buffer. It needs to be atomic
// since multiple threads will be in contention to increment it.
//
// Atomic<T> is the most portable way to express atomic operations. Slang supports basic
// operations like +, -, ++, etc.. on Atomic<T> types.
//
groupshared Atomic<uint> blobCountAT;

// This is used after the coarse rasterization step as a non-atomic
// location to store the blob count, since atomics are not necessary after the coarse
// rasterization step.
//
groupshared uint blobCount;

// The blobs buffer is used to store the indices of the blobs that intersect
// with the current tile.
//
groupshared uint blobs[GAUSSIANS_PER_BLOCK];

Using the groupshared identifier tells Slang that these variables need to be in the fast local memory available to all the threads in a workgroup. This shared memory space is much faster to access than global GPU memory, but it’s very limited in space– sometimes only on the order of tens of kilobytes.

Importantly, we declare the index incrementor, blobCountAT, to be atomic– this ensures that only one thread has access to read or write the variable at a time, preventing multiple threads from trying to simultaneously increment it.

After the threads in the workgroup finish iterating across the full list of blobs to identify the ones relevant to the current tile, we issue another GroupMemoryBarrierWithGroupSync to make sure all the threads in the workgroup finish, before finally writing out the final count of blobs in our shortlist to the non-atomic blobCount variable.

When coarseRasterize() completes, we have a list of just the gaussian blobs which affect the current tile, so we need not iterate through the entire list for each pixel. Because we’re no longer operating on the full list of gaussians, we can no longer assume that the list stays sorted in the back-to-front order needed for alpha blending. Because we built the short list in individual workgroup threads, we don’t know what order they were added to the list using blobs[blobCountAT++] = i;, so we will need to take an additional step for sorting them, which is done with bitonicSort, a sorting algorithm which makes similar use of workgroup shared memory to allow the workgroup threads to collaboratively sort the list.

Now that we have created a reduced list of gaussians to evaluate per-pixel, our rasterization could potentially be much faster! But you may have noticed that the maximum number of GAUSSIANS_PER_BLOCK is defined as 512– more than twice as many as the total list of gaussian blobs we used in our simplified example. Is that going to be a problem?

Differential Propagation and Intermediate Value Storage

There’s a second problem that was causing poor performance in our simplified example, but it’s less obvious, because it’s a byproduct of Slang doing derivative propagation for you.

Looking back at the simplified implementation, the differentiable function we used to calculate blob colors was simpleSplatBlobs():

/* simpleSplatBlobs() is a naive implementation of the computation of color for a pixel.
 * It will iterate over all of the Gaussians for each pixel, to determine their contributions
 * to the pixel color, so this will become prohibitively slow with a very small number of 
 * blobs, but it reduces the number of steps involved in determining the pixel color.
 */
 [Differentiable]
 float4 simpleSplatBlobs(GradInOutTensor<float, 1> blobsBuffer, uint2 pixelCoord, int2 texSize)
 {
    Blobs blobs = {blobsBuffer};

    float4 result = {0.0, 0.0, 0.0, 1.0};
    float4 blobColor = {0.0, 0.0, 0.0, 0.0};

    for (uint i = 0; i < SIMPLE_BLOBCOUNT; i++)
    {
        Gaussian2D gaussian = Gaussian2D.load(blobs, i);
        blobColor = gaussian.eval(pixelCoord * (1.0/texSize));
        
        result = alphaBlend(result, blobColor);
        if (result.a < 1.f / 255.f)
            continue;
    }

    // Blend with background
    return float4(result.rgb * (1.0 - result.a) + result.a, 1.0);
}

Because this function is differentiable, we need to be able to propagate its variables’ values through a chain of derivatives– that is, we need to know the value of result, blobColor, and gaussian at each step through the list of blobs, for every pixel we calculate. Storing all of that information is costly – especially because we’re doing these calculations on the GPU, and very little memory is available to us without significant latency in accessing it.

We can avoid needing to do all of this storage of intermediate values if, instead, we provide a way for Slang to recalculate the values as it progresses through the backward propagation. To do this, we provide a user-defined backwards form for part of our rasterization algorithm.

/*
 * fineRasterize() produces the per-pixel final color from a sorted list of blobs that overlap the current tile.
 *
 * The fine rasterizeration is where the calculation of the per-pixel color happens.
 * This uses the multiplicative alpha blending algorithm laid out in the original GS paper (https://repo-sam.inria.fr/fungraph/3d-gaussian-splatting/)
 * This is represented as a 'state transition' (transformPixelState) as we go through the blobs in order, so that we can
 * concisely represent the 'state undo' operation in the backwards pass.
 *
 * In Slang, custom derivative functions can be defined using the `[BackwardDerivative(custom_fn)]` attribute.
 */
[BackwardDerivative(fineRasterize_bwd)]
float4 fineRasterize(SortedShortList, Blobs blobset, uint localIdx, no_diff float2 uv)
{
    GroupMemoryBarrierWithGroupSync();

    PixelState pixelState = PixelState(float4(0, 0, 0, 1), 0);
    uint count = blobCount;
    // The forward rasterization
    for (uint i = 0; i < count; i++)
        pixelState = transformPixelState(pixelState, eval(blobset, blobs[i], uv, localIdx));

    maxCount[localIdx] = pixelState.finalCount;
    finalVal[localIdx] = pixelState.value;
    return pixelState.value;
}

/*
 * fineRasterize_bwd() is the user-provided backwards pass for the fine rasterization step.
 *
 * This is implemented as a custom derivative function because, while applying auto-diff directly to a function
 * with a loop can result in excessive state caching (a necessary part of standard automatic differentiation methods)
 *
 * For Gaussian splatting, there is a 'state undo' (undoPixelState) operation available. fineRasterize_bwd takes advantage of this
 * to recreate the states at each step of the forward pass instead of letting auto-diff store them.
 *
 * While it is important to represent the backwards loop explicitly in this way, the contents of the loop body (loading, evaluation,
 * blending, etc..) can still be differentiated automatically (and it would be tedious to do so manually).
 *
 * The loop body therefore invokes `bwd_diff` to backprop the derivatives via auto-diff.
 */
void fineRasterize_bwd(SortedShortList, Blobs blobset, uint localIdx, float2 uv, float4 dOut)
{
    GroupMemoryBarrierWithGroupSync();

    PixelState pixelState = { finalVal[localIdx], maxCount[localIdx] };

    PixelState.Differential dColor = { dOut };

    // The backwards pass manually performs an 'undo' to reproduce the state at each step.
    // The inner loop body still uses auto-diff, so the bulk of the computation is still
    // handled by the auto-diff engine.
    //
    for (uint _i = blobCount; _i > 0; _i--)
    {
        uint i = _i - 1;
        var blobID = blobs[i];
        var gval = eval(blobset, blobID, uv, localIdx);
        var prevState = undoPixelState(pixelState, i + 1, gval);

        var dpState = diffPair(prevState);
        var dpGVal = diffPair(gval);

        // Once we have the previous state, we can continue with the backpropagation via auto-diff within
        // the loop body. Note that the `bwd_diff` calls writeback the differentials to dpState and dpGVal,
        // and can be obtained via `getDifferential()` (or simply '.d')
        //
        bwd_diff(transformPixelState)(dpState, dpGVal, dColor);
        bwd_diff(eval)(blobset, blobID, uv, localIdx, dpGVal.getDifferential());

        pixelState = prevState;
        dColor = dpState.getDifferential();
    }
}

The first thing you’ll notice here is that, rather than simply being annotated as [Differentiable], our fineRasterize() function uses [BackwardDerivative(fineRasterize_bwd)] to indicate that, rather than Slang generating the backwards form of this function automatically, we instead want to provide the backward form of this function ourselves. Whereas before, we were storing the pixel state value for each iteration of the loop so that it could be replayed backwards, we now can use our domain-specific knowledge to reproduce the required value at each iteration instead.

Manually providing a backwards derivative form might seem like it defeats the purpose of using autodiff in Slang in the first place, but one of the very useful things about Slang is that it allows you to mix automatic and user-defined differentiation in a single propagation chain. That is, we can call fineRasterize() from within an automatically differentiated function (in this case, our top-level splatting function, splatBlobs()), provide a user-defined backwards form for just that function, and even invoke automatic differentiation on parts of that user-defined function using bwd_diff(). This way, we can get the benefits of avoiding that automatic caching of intermediate values during our pixel blending loop, but not have to take on all of the work of doing the derivatives for our full rasterization algorithm ourselves.

So, in the code above, the backward form of fineRasterize() loops backward over all of our blobs, evaluates each one, and performs an “undo” operation, which we define in undoPixelState.

/*
 * undoPixelState() reverses the alpha blending operation and restores the previous pixel
 * state.
 */
PixelState undoPixelState(PixelState nextState, uint index, float4 gval)
{
    if (index > nextState.finalCount)
        return { nextState.value, nextState.finalCount };

    return { undoAlphaBlend(nextState.value, gval), nextState.finalCount - 1 };
}

// …

/*
 * undoAlphaBlend() implements the reverse of the alpha blending algorithm.
 *
 * Takes a pixel value 'pixel' and the same 'gval' contribution &
 * computes the previous pixel value.
 *
 * This is a critical piece of the backwards pass.
 */
float4 undoAlphaBlend(float4 pixel, float4 gval)
{
    gval = preMult(gval);

    var oldPixelAlpha = pixel.a / (1 - gval.a);
    return float4(
        pixel.rgb - gval.rgb * oldPixelAlpha,
        oldPixelAlpha);
}

One thing to note about undoing an alpha blend: because alpha values are all within the range [0.0, 1.0], our undo is only possible if the pixel never becomes fully opaque. This is handled inside the transformPixelState function called by fineRasterize:

/*
 * transformPixelState() applies the alpha blending operation to the pixel state &
 * updates the counter accordingly.
 *
 * This state transition also stops further blending once the pixel is effectively opaque.
 * This is important to avoid the alpha becoming too low (or even 0), at which point
 * the blending is not reversible.
 *
 */
[Differentiable]
PixelState transformPixelState(PixelState pixel, float4 gval)
{
    var newState = alphaBlend(pixel.value, gval);

    if (pixel.value.a < 1.f / 255.f)
        return { pixel.value, pixel.finalCount };

    return { newState, pixel.finalCount + 1 };
}

Local Index Mapping

There’s one other notable difference between the simplified and full versions of this 2D gaussian splatter, which I mentioned above: the dispatch shape.

In the simplified version, we initiated the backward derivative propagation with this line of SlangPy:

module.perPixelLoss.bwds(per_pixel_loss,
                         spy.grid(shape=(input_image.width,input_image.height)),
                         blobs, input_image)

Recall that the spy.grid() function is a generator, which produces a grid-shaped set of IDs for the individual threads running the dispatched work.

By contrast, in this more complex version, we want to ensure that the coarseRasterize() and bitonicSort() functions can operate collaboratively on a set of pixels within a workgroup, so we create a mapping of pixels to thread IDs:

def calcCompressedDispatchIDs(x_max: int, y_max: int, wg_x: int, wg_y: int):
    local_x = np.arange(0, wg_x, dtype=np.uint32)
    local_y = np.arange(0, wg_y, dtype=np.uint32)
    local_xv, local_yv = np.meshgrid(local_x, local_y, indexing="ij")
    local_xyv = np.stack([local_xv, local_yv], axis=-1)
    local_xyv = np.tile(local_xyv.reshape(wg_x * wg_y, 2).astype(np.uint32),
                        ((x_max // wg_x) * (y_max // wg_y), 1))
    local_xyv = local_xyv.reshape((x_max * y_max, 2))

    group_x = np.arange(0, (x_max // wg_x), dtype=np.uint32)
    group_y = np.arange(0, (y_max // wg_y), dtype=np.uint32)
    group_xv, group_yv = np.meshgrid(group_x, group_y, indexing="ij")
    group_xyv = np.stack([group_xv, group_yv], axis=-1)
    group_xyv = np.tile(group_xyv[:, :, None, None, :], (1, 1, wg_y, wg_x, 1))
    group_xyv = group_xyv.reshape((x_max * y_max, 2)).astype(np.uint32)

    return ((group_xyv * np.array([wg_x, wg_y])[None, :] + local_xyv).astype(np.uint32))

What’s happening here is that we’re using some utility functions from NumPy to construct a grid of IDs manually, rather than asking SlangPy to generate it for us. We’re also providing the values in a single array, because, behind the scenes, SlangPy currently only supports a 1D dispatch shape– more general dispatch support is planned to be added soon. x_max and y_max represent the size of the full image, while wg_x and wg_y are the dimensions of the tile (and the workgroup that will calculate the pixel values within that tile). The IDs we create tell each thread both where it’s located within its workgroup, and which workgroup it belongs to within the full work dispatch, and from those, what pixel coordinates it’s responsible for calculating. We can then provide this set of IDs directly to our perPixelLoss function at dispatch:

module.perPixelLoss.bwds(per_pixel_loss, dispatch_ids, blobs, input_image)

Results

With these optimizations, we’re now able to operate on a much larger set of gaussian blobs. The full diff-splatting experiment uses 40960 blobs in total (and correspondingly defines their maximum size to be smaller, since we don’t need to cover as much ground with each blob). And even with this much larger number of blobs, overall execution is much faster. On the same system I used to generate the last post’s example image, all 10,000 iterations now take less than 3 minutes (compared to around 40 minutes for the simplified version). And as you can see, the image quality is orders of magnitude better.

This optimization journey may feel familiar to graphics developers - we’ve applied many classic optimization patterns like tile-based processing, efficient memory management, and parallel workgroup coordination. The same patterns that have served graphics developers for years are equally crucial in neural graphics applications. The other part of our optimization equation is the mixing of automatic and user-defined differentiation, allowing us to use what we know about our color accumulation operation to avoid storage overhead, which is a particular strength of Slang. But whether you’re rendering traditional polygons or training neural representations, the underlying challenges of efficient hardware utilization remain remarkably similar.

You can start experimenting with the code for this 2D gaussian splatting example in a couple of ways: to try out the sample from SlangPy, check out the code in our SlangPy experiments set. If you want to try it out in your browser, head over to the Slang Playground, which uses the same Slang code in WebGPU.

Welcome Our Newest Slang Committers!

Thu, 24 Apr 2025 17:00:00 +0000

We’re thrilled to celebrate two outstanding members of the Slang community who have recently become committers: fairywreath and juliusikkala! Their elevation to committer status recognizes their significant contributions to Slang and their ongoing commitment to improving the shader programming ecosystem.

Meet Our New Committers

fairywreath

fairywreath has demonstrated exceptional expertise in cross-platform shader development and advanced GPU features. Their contributions have significantly expanded Slang’s capabilities:

Advanced GPU Features: Implemented cooperative matrix support, subgroup operations, and shader intrinsics, enabling more powerful GPU computations
Cross-Platform Support: Added crucial features for Metal and WGSL targets, including wave operations and structured buffer support
Graphics Pipeline Enhancement: Contributed mesh shader improvements, SPIRV debugging capabilities, and floating-point pack/unpack intrinsics

Their work has been particularly impactful in making Slang more powerful and consistent across different graphics APIs and hardware platforms.

juliusikkala

juliusikkala has made substantial contributions across multiple areas of Slang, demonstrating deep technical expertise in compiler development and language design. Their work has significantly improved Slang’s capabilities in several key areas:

Language Enhancement: Implemented the defer statement, providing developers with more powerful control flow options, and added support for specialization constants in compute shader thread configurations
Cross-Platform Compatibility: Improved GLSL compatibility and SPIR-V output, making Slang more reliable across different graphics APIs
Compiler Robustness: Fixed critical issues in generic specialization, optimization, and type handling, enhancing the compiler’s reliability and performance

Their consistent attention to detail and commitment to code quality has helped make Slang more robust and feature-rich for all users.

Why Committers Matter

Committers play a crucial role in the Slang ecosystem. They help review code, mentor new contributors, and shape the future direction of the project.

Join the Slang Community

Interested in becoming a Slang committer? The path to becoming a committer starts with getting involved in the community. Visit our Community Page to learn more.

Welcome again to our new committers, and thank you to all our community members who make Slang better every day!

Neural Graphics in an Afternoon

Fri, 04 Apr 2025 17:00:00 +0000

(For the next article in this series, click here)

The intersection of computer graphics and machine learning is creating exciting new possibilities, from scene reconstruction with NeRFs and Gaussian splats to learning complex material properties. But getting started with neural graphics can seem daunting. Between understanding graphics APIs, shader programming, and automatic differentiation, there’s a lot to learn. That’s why the Slang team is introducing SlangPy, a new Python package that makes it dramatically easier to build neural graphics applications with Slang. With just a few lines of Python code, you can now:

Seamlessly call Slang functions on the GPU from Python
Leverage automatic differentiation without writing complex derivative code
Eliminate graphics API boilerplate and reduce potential bugs
Integrate with popular ML frameworks like PyTorch
Rapidly prototype and experiment with neural graphics techniques

In this article, I’ll show you how to write your first neural graphics program with Slang and SlangPy by walking through our 2D Gaussian Splatting example.

Example: 2D Gaussian Splatting

Our concrete example, which you can see in action on the Slang playground, uses 2D Gaussian splats (think of them as fuzzy circular blobs of color) to represent an image. Each splat has properties for:

Position (where it’s centered)
Sigma (how fuzzy/spread out it is)
Color

Why are Gaussian splats so powerful? Their mathematical properties make them particularly well-suited for representing visual information. Each Gaussian splat naturally creates smooth gradients from its center outward, which is perfect for capturing how light and color blend in real-world scenes. And because of this smoothness, they are well suited to optimization techniques like the one we are about to explore. In more advanced applications, these properties allow Gaussian splats to represent complex 3D scenes with remarkably high visual quality while maintaining real-time performance – a sweet spot that’s made them increasingly popular in computer graphics applications from virtual production to AR/VR.

The challenge is: how do we determine the right parameters for thousands of splats to recreate a specific image? To do this, we can use a technique common in machine learning called gradient descent. Gradient descent can be used to find an optimal solution to a problem by making small adjustments to its inputs and checking whether they bring the result closer to our desired output. The basic idea is that we start with random splat properties, and define a “loss function”, which measures how different the resulting image is from what we want it to be, and then use gradient descent to adjust the splat properties until the difference is minimized.

The Challenge: Computing Gradients

That’s where things get a little tricky. There’s a mathematical operation to express how a function changes as you change one of its inputs– the derivative. A gradient is a collection of partial derivatives of a function with respect to each of its input parameters. If that sounds scary: don’t worry, Slang is here to help!

Without Slang, calculating derivatives of our loss function with respect to every parameter can get very laborious. For complex graphics operations, this means:

Writing both the function itself, and a corresponding function (the derivative of the original) which calculates the gradients. These are referred to as the “forward” and “backward” forms of the function.
Making sure that any changes made to the original (forward) form of the function are also done correctly to its differential (backward) form.
Actually doing the derivatives, which can get extremely complex for an arbitrary shader function

Slang makes this entire process much easier, because it can automatically calculate the backward form of your shader functions for you. You can take advantage of the power of gradient descent without having to wade hip-deep (or even dip your toes) into calculus.

The Code

Let’s take a look at what it looks like to do this in the code. I’ll first go through a simplified version of the 2D Gaussian splatting example, so it’s very clear how the mechanism works. You can find this example in the SlangPy repository here. First, we’ll check out the Python side of things. With SlangPy, this code is pretty succinct.

# SPDX-License-Identifier: Apache-2.0

import slangpy as spy
import pathlib
import imageio
import numpy as np

# Create a device, which will handle setup and invocation of the Slang
# compiler for us. We give it both the slangpy PATH and the local include
# PATH so that it can find Slang shader files
device = spy.Device(
    compiler_options={
        "include_paths": [
            spy.SHADER_PATH,
            pathlib.Path(__file__).parent.absolute(),
        ],
    }
)

# Load our Slang module -- we'll take a look at this in just a moment
module = spy.Module.load_from_file(device, "simplediffsplatting2d.slang")

# Create a buffer to store Gaussian blobs. We're going to make a very small one,
# because right now this code is not very efficient, and will take a while to run.
# For now, we are going to create 200 blobs, and each blob will be comprised of 9
# floats:
#   blob center x and y (2 floats)
#   sigma (a 2x2 covariance matrix - 4 floats)
#   color (3 floats)
NUM_BLOBS = 200
FLOATS_PER_BLOB = 9
# SlangPy lets us create a Tensor and initialize it easily using numpy to generate
# random values. This Tensor includes storage for gradients, because we call .with_grads()
# on the created spy.Tensor.
blobs = spy.Tensor.from_numpy(
    device, np.random.rand(NUM_BLOBS * FLOATS_PER_BLOB).astype(np.float32)
).with_grads()

# Load our target image from a file, using the imageio package,
# and store its width and height in W, H
image = imageio.imread("./jeep.jpg")
W = image.shape[0]
H = image.shape[1]

# Convert the image from RGB_u8 to RGBA_f32 -- we're going
# to be using texture values during derivative propagation,
# so we need to be dealing with floats here.
image = (image / 256.0).astype(np.float32)
image = np.concatenate([image, np.ones((W, H, 1), dtype=np.float32)], axis=-1)
input_image = device.create_texture(
    data=image,
    width=W,
    height=H,
    format=spy.Format.rgba32_float,
    usage=spy.TextureUsage.shader_resource,
)

# Create a per_pixel_loss Tensor to hold the calculated loss, and create gradient storage
per_pixel_loss = spy.Tensor.empty(device, dtype=module.float4, shape=(W, H))
per_pixel_loss = per_pixel_loss.with_grads()
# Set per-pixel loss' derivative to 1 (using a 1-line function in the slang file)
module.ones(per_pixel_loss.grad_in)

# Create storage for the Adam update moments
# The Adam optimization algorithm helps us update the inputs to the function being optimized
# in an efficient manner. It stores two "moments": the first is a moving average of the
# of the gradient of the loss function. The second is a moving average of the squares of these
# gradients. This allows us to "step" in the desired direction while maintaining momentum toward
# the goal
adam_first_moment = spy.Tensor.zeros_like(blobs)
adam_second_moment = spy.Tensor.zeros_like(blobs)

# Pre-allocate a texture to send data to tev occasionally.
current_render = device.create_texture(
    width=W,
    height=H,
    format=spy.Format.rgba32_float,
    usage=spy.TextureUsage.shader_resource | spy.TextureUsage.unordered_access,
)

iterations = 10000
for iter in range(iterations):
    # Back-propagage the unit per-pixel loss with auto-diff.
    module.perPixelLoss.bwds(
        per_pixel_loss, spy.grid(shape=(input_image.width, input_image.height)), blobs, input_image
    )

    # Update the parameters using the Adam algorithm
    module.adamUpdate(blobs, blobs.grad_out, adam_first_moment, adam_second_moment)

    # Every 50 iterations, render the blobs out to a texture, and hand it off to tev
    # so that you can visualize the iteration towards ideal
    if iter % 50 == 0:
        module.renderBlobsToTexture(
            current_render, blobs, spy.grid(shape=(input_image.width, input_image.height))
        )
        spy.tev.show_async(current_render, name=f"optimization_{(iter // 50):03d}")
    

This is the entire Python file for setting up, initializing a set of 2D Gaussian blobs, and kicking off the derivative propagation that calculates the ideal values for all those blob parameters. The setup should be fairly straightforward and explained by the comments, so let’s take a closer look at the “meat” of this file, iterating through our gradient descent.

iterations = 10000
for iter in range(iterations):
    # Back-propagage the unit per-pixel loss with auto-diff.
    module.perPixelLoss.bwds(per_pixel_loss,
                             spy.grid(shape=(input_image.width,input_image.height)),
                             blobs, input_image)

What the module.perPixelLoss.bwds() call is doing is going into the Slang module we loaded above, finding the perPixelLoss() function defined within it, and invoking the backwards differential form. The parameters we pass are:

per_pixel_loss - A tensor we created to store the loss value for each pixel of the calculated image
spy.grid(shape=(input_image.width, input_image.height)) - This is part of what makes SlangPy so helpful. Much like the thread ID of a traditional compute kernel, SlangPy has a way for your kernel to know what thread it’s operating on in the context of the full dispatch. But what makes it especially handy for ML use cases is that Slang’s generator functions support arbitrary dimensionality, as opposed to the 3D-maximum in most traditional compute paradigms. There are several generator methods provided by SlangPy; grid() is the one we want here because we can be explicit about the shape of the work we’re dispatching. We’re computing the values of a width x height image, and so we want to consider our compute threads in that context, so we provide those values to the grid function, and it will generate appropriate identifier information for each of the invocations of the kernel.
blobs - The tensor full of all the blob parameters, which also has storage for gradients associated with each of the blobs. Those gradients will give us the information we need to know which direction to adjust each parameters to get closer to our desired target output.
input_image - The target image that we’re trying to get our blobs to look like

When this call finishes, per_pixel_loss will contain values representing the results of the loss function for each pixel based on the “calculated image” that results from all of our current blob parameters, and blobs will have a gradient associated with each blob, indicating which direction the parameters should move in order to get closer to the target. The input image will be unchanged.

    # Update the parameters using the Adam algorithm
    module.adamUpdate(blobs, blobs.grad_out, adam_first_moment, adam_second_moment)

This line calls into a Slang function in our module which provides an optimized algorithm for updating our blobs based on the information stored in the blob gradients. It calculates moving averages of these gradients, so that we can update our blob parameters efficiently. You can read more about how Adam works in the paper that introduced it, and you’ll see the implementation in our Slang module in a moment. Don’t worry– it’s less than thirty lines of Slang code!

    # Every 50 iterations, render the blobs out to a texture, and hand it off to tev
    # so that you can visualize the iteration towards ideal
    if iter % 50 == 0:
        module.renderBlobsToTexture(
            current_render, blobs, spy.grid(shape=(input_image.width, input_image.height))
        )
        spy.tev.show_async(current_render, name=f"optimization_{(iter // 50):03d}")

And then finally, we use one last function in our Slang module to render the results of our blobs out to a texture, instead of just keeping them in memory, so that we can visualize the results of the iterations as we go on. We’re doing 10 thousand iterations, though, so looking at every iteration might be overkill, so we’ll only render out every 50th iteration.

Ok! Now, for the Slang side of things.

There’s a bit more to the Slang code, but let’s first take a look at the functions that we called out to from SlangPy just a moment ago. The workhorse of the module is that perPixelLoss() function and its helpers:

// simpleSplatBlobs() is a naive implementation of the computation of color for a pixel.
// It will iterate over all of the Gaussians for each pixel, to determine their contributions
// to the pixel color, so this will become prohibitively slow with a very small number of
// blobs, but it reduces the number of steps involved in determining the pixel color.
//
[Differentiable]
float4 simpleSplatBlobs(GradInOutTensor<float, 1> blobsBuffer, uint2 pixelCoord, int2 texSize)
{
    Blobs blobs = {blobsBuffer};
    
    float4 result = {0.0, 0.0, 0.0, 1.0};
    float4 blobColor = {0.0, 0.0, 0.0, 0.0};
    
    // iterate over the full list of Gaussion blobs
    for (uint i = 0; i < SIMPLE_BLOBCOUNT; i++)
    {
        // first, calculate the color of the current blob
        Gaussian2D gaussian = Gaussian2D.load(blobs, i);
        blobColor = gaussian.eval(pixelCoord * (1.0/texSize));
    
        // then, blend with the blobs we've accumulated so far
        result = alphaBlend(result, blobColor);
    }
    
    // Blend with background
    return float4(result.rgb * (1.0 - result.a) + result.a, 1.0);
}

//
// loss() implements the standard L2 loss function to quantify the difference between
// the rendered image and the target texture.
//
[Differentiable]
float loss(uint2 pixelCoord, int2 imageSize, Blobs blobs, Texture2D<float4> targetTexture)
{
    int texWidth;
    int texHeight;
    targetTexture.GetDimensions(texWidth, texHeight);
    int2 texSize = int2(texWidth, texHeight);

    // Splat the blobs and calculate the color for this pixel.
    float4 color = simpleSplatBlobs(blobs.blobsBuffer, pixelCoord, imageSize);
    float4 targetColor;
    
    float weight;
    if (pixelCoord.x >= imageSize.x || pixelCoord.y >= imageSize.y)
    {
        return 0.f;
    }
    else
    {
        targetColor = no_diff targetTexture[pixelCoord];
        return dot(color.rgb - targetColor.rgb, color.rgb - targetColor.rgb);
    }
    
    return 0.f;
}

// Differentiable function to compute per-pixel loss
// Parameters:
// output: a 2-dimensional tensor of float4 values, representing the output texture
// pixelCoord: the coordinates of the output pixel whose loss is being calculated
// blobsBuffer: a 1-dimensional tensor of floats, containing the Gaussian blobs

[Differentiable]
void perPixelLoss(GradInOutTensor<float4, 2> output,
                  uint2 pixelCoord,
                  GradInOutTensor<float, 1> blobsBuffer,
                  Texture2D<float4> targetTexture)
{
    uint2 imageSize;
    targetTexture.GetDimensions(imageSize.x, imageSize.y);
    output.set( {pixelCoord.x, pixelCoord.y},
    loss(pixelCoord, imageSize, {blobsBuffer}, targetTexture));
}

You can see in this code block that simpleSplatBlobs() is doing most of the work: iterating over our entire list of Gaussian blobs, and accumulating their contributions to the color of the pixel we are currently calculating. Keep in mind that perPixelLoss() is going to be invoked once for each pixel in the output image, so the function is figuring out the loss value for just a single pixel.

You might wonder if iterating over our entire list of Gaussians for each pixel in the image might be slow. It is. There are some clever things that we can do to speed up this calculation considerably, which I’ll cover in a follow-up blog post, but for now, let’s just focus on the simple– but slow– version.

This set of functions is responsible for calculating all of the output pixels, as well as the difference between those values and our ideal target image, so they’re invoked not just for propagating loss derivatives (the module.perPixelLoss.bwds call we made in Python), but also during the rendering of our output texture, via renderBlobsToTexture, which looks like this:

void renderBlobsToTexture(
    RWTexture2D<float4> output,
    GradInOutTensor<float, 1> blobsBuffer,
    uint2 pixelCoord)
{
    uint2 imageSize;
    output.GetDimensions(imageSize.x, imageSize.y);
    output[pixelCoord] = simpleSplatBlobs(blobsBuffer, pixelCoord, imageSize);
}

As you can see, this function just takes the result of simpleSplatBlobs, and writes the value to the appropriate pixel location in the output texture.

The other piece of the equation is the Adam update algorithm:

void adamUpdate(inout float val,
                inout float dVal,
                inout float firstMoment,
                inout float secondMoment)
{
    // Read & reset the derivative
    float g_t = dVal;

    float g_t_2 = g_t * g_t;

    //
    // Perform a gradient update using Adam optimizer rules for
    // a smoother optimization.
    //
    float m_t_prev = firstMoment;
    float v_t_prev = secondMoment;
    float m_t = ADAM_BETA_1 * m_t_prev + (1 - ADAM_BETA_1) * g_t;
    float v_t = ADAM_BETA_2 * v_t_prev + (1 - ADAM_BETA_2) * g_t_2;

    firstMoment = m_t;
    secondMoment = v_t;

    float m_t_hat = m_t / (1 - ADAM_BETA_1);
    float v_t_hat = v_t / (1 - ADAM_BETA_2);

    float update = (ADAM_ETA / (sqrt(v_t_hat) + ADAM_EPSILON)) * m_t_hat;
    val -= update;
    dVal = 0.f;
}

This function isn’t marked as differentiable, because we don’t need to do any derivatives here– it’s just a straightforward update of all the blob parameters based on our gradients.

And… that’s essentially it! Other than a few utility functions, this is all you need to write code that trains itself to match an output image. Your first neural graphics shader!

Now, there are some notable shortcomings in this example– primarily, as mentioned before, that it takes quite a long time to execute. Because we look through our entire list of Gaussian blobs once for every pixel being calculated, at every iteration, it takes about 40 minutes (for me, on a system with a six-year-old graphics card) for all 10,000 iterations to complete. And this is with a very small number of blobs; I limited the number of blobs used to generate the image to 200, because going beyond that point starts to hang my GPU. And because of the small number of blobs, you can see that the image is pretty fuzzy. We could counter this with more, smaller blobs, but doing that will require some clever changes to improve execution speed. Thankfully, this is exactly the sort of work that GPUs are good at! And now that we’ve got the hang of how gradient descent and gaussian splatting work, we can dive into the optimization work in a follow-on blog post.

If you have any questions or comments on this example code, or things you’d like to see covered in future walkthrough blog posts, please join us on the Slang Discord – I and the rest of the Slang team can be found hanging out and answering questions there!

Now Available: Matrix-vector operations using tensor cores

Thu, 30 Jan 2025 20:00:00 +0000

Just released, the SPV_NV_cooperative_vector extension in SPIR-V provides a new set of types to SPIR-V, and Slang has added experimental support for these cooperative vectors as well, so that you can make use of these types when targeting SPIR-V. Cooperative vectors enable shaders to do matrix operations utilizing hardware specialized for tensor operations on GPUs where they are available.

A cooperative vector is an opaque vector type. Unlike normal vector types, they can have arbitrary length and support a relatively limited set of operations. These types are intended to help accelerate the evaluation of small neural networks, where each invocation is performing its own independent evaluation of the network. Behind the scenes, the hardware will try to share calculations as much as possible within a given subgroup, which can improve the performance compared to a traditional implementation.Therefore, while using cooperative vectors to perform multiplications with different matrices in a subgroup is supported by this feature, it’s best to reduce the data divergence as much as possible to achieve best performance.

Slang’s support for cooperative vectors is currently an experimental feature. For more details on what you can expect from experimental features, and how they are expected to progress to stable status, please check out our language change process documentation.

Cooperative vector is currently available as a vendor extension in SPIR-V (SPV_NV_cooperative_vector), and developers will need a driver that supports this extension in order to use it. Cooperative vectors are permitted in any stage in SPIR-V with this extension. If cooperative vector support is added to other target platforms, they may have different restrictions.

Full documentation of cooperative vector operations in Slang can be found in the cooperative vector feature proposal

Code Examples

The following code snippet shows a simple example of how to use cooperative vectors in a Slang compute shader:

// Slang shader with Cooperative Vector support

ByteAddressBuffer inputBuffer1;
ByteAddressBuffer inputBuffer2;
RWStructuredBuffer<int32_t> outputBuffer;

[numthreads(4, 4, 1)]
void computeMain(int threadID : SV_DispatchThreadID)
{
    CoopVec<int32_t,32> lhs = coopVecLoad<32, int32_t>(inputBuffer1);
    CoopVec<int32_t,32> rhs = coopVecLoad<32, int32_t>(inputBuffer2);
    let result = lhs + rhs;

    for(int i = 0; i < result.getCount(); ++i)
        outputBuffer[threadID*32 + i] = result[i];
}

This compute shader loads 32 values from a shader parameter, inputBuffer, and stores them in a local variable, result, whose type is CoopVec<int,32>.

Note that the variable result is a vector with 32 elements, which is much longer than a traditional vector, whose size ranges up to 4.

The following code snippet shows another example that performs a matrix multiplication with a cooperative vector:

// Slang shader with Cooperative Vector support

ByteAddressBuffer input; // [1 2 3 4 …]
ByteAddressBuffer matrix; // [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16]
RWStructuredBuffer<int32_t> outputBuffer;

[numthreads(16, 1, 1)]
void computeMain(int threadID : SV_DispatchThreadID)
{
    CoopVec<int8_t, 4> vec = coopVecLoad<4, int8_t>(input, threadID * 4 * sizeof(float));
    let result = coopVecMatMul<int32_t, 4, 4>(
        vec, // input vector
        CoopVecComponentType::SignedInt8, // vector interpretation
        matrix, // input matrix
        0, // matrix offset in byte
        CoopVecComponentType::SignedInt8, // matrix interpretation
        CoopVecMatrixLayout::RowMajor, // matrix layout
        false, // matrix transpose
        4 // matrix stride
    );

    for(int i = 0; i < result.getCount(); ++i)
        outputBuffer[threadID*4 + i] = result[i]; // [30 70 110 150 …]
}

This compute shader loads 4 values and stores them in a cooperative vector variable, vec. The coopVecMatMul() function performs matrix multiplication with a given vector and a given matrix.

Note that most cooperative vector functions take “interpretation” parameters. If a target platform doesn’t directly support the int8 type, the interpretation parameter can allow you to use smaller data types for the calculation.

For more practical examples of Cooperative Vector usage, please see the RTX Neural Shading and RTX Neural Texture Compression (NTC) SDKs that will be released soon within RTX Kit. NTC contains implementations of neural texture decompression using Cooperative Vectors in Slang, as well as fallback implementations of the same using traditional shader math. On recent NVIDIA GPUs, using Cooperative Vectors can provide up to 4x speedup in decompression compared to using DP4a instructions.

Slang Development Update - January 2025

Fri, 10 Jan 2025 19:00:00 +0000

Happy new year, Slang enthusiasts! As we beckon in 2025, we wanted to take a moment to highlight the many improvements we’ve been able to land in response to the incredible and enthusiastic engagement and feedback from the Slang community! Take a look at what’s new:

Improvement on specialization constants and push constants

Specialization constants are now supported for WGSL and Metal targets.
Fixed reflection API issues around specialization constants and push constants.
Added more validation checks on invalid use of specialization/push constant attributes.

Improvement on SPIRV pointer support

Added loadAligned and storeAligned intrinsics for aligned load/stores.
Now supports pointers to a struct with trailing unsized arrays.
Dynamic dispatch via interface-typed pointers are now supported.
Reflection on pointer element type now correctly reports the scalar layout.

SPIRV/GLSL improvements

Added SV_DrawIndex semantic that maps to the DrawIndex builtin
Added Sampler2DShadow and friends to combined texture comparison-sampler types.
Explicit GLSL binding locations (as in [vk::binding()] and in layout(binding=…) qualifiers) can now use compile time expressions. (contribution from community)
-fvk-invert-y option now works for mesh shader position outputs.
Added nonuniformEXT intrinsics when consuming GLSL code.

Reflection API and binding improvement

Explicit [vk::location(N)] binding is now supported for WGSL and Metal targets.
IMetadata::isParameterLocationUsed now supports reporting usage info on stage varying inputs/outputs.
Now support querying both user defined and system builtin attributes on types and functions with the new findAttributeByName API.
Attribute::getArgumentValueByFloat now correctly returns the value even if the argument in the source code is in the form of a integer literal.
WGSL backend now respects explicit binding qualifiers.

These improvements are available in Slang v2025.2.

Thank you to everyone in the Slang community for your feedback and your contributions! We’d also like to recognize GitHub users @juliusikkala and @fairywreath for landing a number of fixes and improvements.

We’re also happy to share that the video and slides from last month’s Slang Birds of a Feather session are now available! This was a great session, with a full room of developers who brought insightful questions – give it a watch!

Documentation Update: Reflection API

Wed, 18 Dec 2024 18:00:00 +0000

The Slang reflection API gives developers the ability to examine shader parameters, types, and their layouts from their application during runtime – a big benefit for things like dynamic shader parameter binding. Based on user feedback, we’ve given the documentation for reflection a major update, making it easier to understand how to interact with and use it to your best advantage.

The basic reflection API documentation provides an overview of best practices for retrieving reflection information from a compiled shader, and how Slang reports out the individual variables and types and their layouts. It also references a simple example to demonstrate how the code is used in practice, and provides coverage of details like how to calculate offsets into parameter blocks, how Slang handles global parameter declarations, and how to avoid common pitfalls.

For developers targeting multiple API environments, we’ve also put together an overview of one strategy for handling parameter passing in a cross-platform safe way in our shader cursors documentation. Because the way in which different GPU APIs accept parameters from the caller varies significantly, handing that information off to your shader program is something that many developers wrestle with. Slang’s reflection API was designed with this understanding in mind, to help you manage shader parameters wherever you need to deploy, across the wide range of targets that Slang supports.

We’re continuing to add to our reflection API documentation, so stay tuned for more updates! And if there are areas you’d like to see more detailed documentation, please let us know – you can join us at any time on our Discord server!

Slang Support Now Available on Godbolt Compiler Explorer

Tue, 17 Dec 2024 18:00:00 +0000

Great news: Slang support is now officially available on Godbolt Compiler Explorer!

Godbolt Compiler Explorer is a widely-used online tool that allows developers to write code in various programming languages and see the resulting assembly code in real-time. This powerful resource helps users understand how high-level code translates to lower-level instructions, making it an invaluable educational and debugging tool. For Slang, this provides an avenue for viewing the SPIR-V, HLSL, GLSL, WGSL, or other output for a given Slang program directly in a compiler explorer tool which may already be familiar to you.

The Slang team is very grateful to the efforts of LunarG engineer Spencer Fricke in integrating Slang support to the Compiler Explorer!

Slang and the 3D Shading Language Landscape

Wed, 04 Dec 2024 10:00:00 +0000

Khronos Hosts Open Source Slang Shading Language and Compiler

Thu, 21 Nov 2024 10:00:00 +0000

The Khronos Group has announced the launch of the new Slang™ Initiative. This initiative will oversee and advance the open-source Slang shading language and compiler, building on 15 years of research, development, and deployment experience. Supported by NVIDIA since 2017, Slang has been widely adopted in production projects across the industry.

There’s a lot going on with Slang!

Wed, 20 Nov 2024 10:00:00 +0000

If you’ve been following Slang developments, you’ve probably noticed a lot of changes happening recently! We’ve been hard at work, and we’re excited to share the latest updates with the Slang community.

Slang: Now a Khronos Open-Source Project!

Probably the most noticeable change around here is the new look and feel of the website, which reflects a big move for the Slang project: we have just finished migrating the Slang open source project to Khronos, the industry consortium dedicated to building an open ecosystem of acceleration standards, formats and open source.

With Slang now hosted at Khronos, it’s no longer tied to any single company, fostering even broader community and industry collaboration. We’ve opened up Slang’s development and decision-making processes, added new documentation on community and developer practices, and launched a Slang Discord for ongoing technical conversations. Slang participation is open to everyone, and it’s now easier than ever to get involved—whether as a Slang contributor, committer, or code owner!

But there’s a lot more than just license and governance changes going on—we’ve introduced many new features in the last few months. Here is a detailed look at the recent advancements, all available in the v2024.14.5 release:

Metal Support

One of the biggest enhancements in recent months is support for Apple’s Metal shading language as a backend target. This opens up new possibilities for developers targeting iOS and macOS platforms, bringing the power of Slang shaders to even more applications and games. Slang’s Metal support includes vertex, fragment, compute, mesh, and amplification shaders.

WebGPU Support

But Metal Shading Language is not the only new backend, Slang can now also compile to WGSL for WebGPU! WebGPU is the latest graphics API for the web, providing high-performance and flexible access to GPU capabilities. With Slang’s new WebGPU support, developers can now compile and run Slang shaders directly in the browser, making it easier than ever to create immersive and interactive web experiences.

Live Playground

To make it easier for developers to experiment with and learn Slang, we have launched a live playground. This online tool allows you to compile Slang shaders to various targets, including GLSL, HLSL, MSL, and WGSL, and run them directly in your browser.

The live playground runs the full Slang compiler as a WebAssembly module, compressed to just 5MB! This allows all shader compilations to run locally in the browser, with no data sent to the cloud. When WebGPU is available in the browser, the playground can execute Slang code by cross-compiling it to WGSL.

The live playground provides an interactive and user-friendly environment where you can test and refine your shaders in real-time– including leveraging the integrated language server support. Whether you are a seasoned developer or just starting out, the live playground is a valuable resource for exploring the capabilities of Slang.

Focus on Auto-Diff Performance

The recent release of a Slang implementation of the original Gaussian Splatting rasterizer has given us the opportunity to scrutinize and improve the performance of Slang’s automatic differentiation, with the end result that we have achieved performance parity between Slang’s auto-diff code and the hand-written CUDA implementation, showing the potential to easily create high performance neural shaders..

NVIDIA Falcor research rendering framework using Slang

Atomic<T>

Atomic operations are implemented differently across different shading languages. While HLSL allows atomic operations on arbitrary types, Metal Shading Language (MSL) and WGSL restrict them to be used only on atomic types. In order to be able to use atomics across all supported backends, Slang has added the Atomic type, allowing developers to use atomics directly in Slang and have them be translated cleanly into the relevant target languages.

New Type-System Features

We have further expanded Slang’s type system to support where clauses, variadic generics, Tuple types, IFunc interfaces, and extensions on generic types. These additions make it easier to implement more advanced shader architectures using Slang, with code that is much easier to maintain than preprocessor macro expansion or external code generation (meta-programming) logic.

Unicode support

Not everyone writes ASCII-only code, and so Slang now accepts Unicode, including in identifier names.

Improved Documentation and Sample Material

We understand the importance of comprehensive documentation and high-quality sample material in helping developers get the most out of Slang, so we’ve been expanding and improving the Slang Developer Documentation Suite, adding samples and reference material. Please let us know where you’d like to see more!

Join Us!

We invite you to join us on Slang’s ongoing journey to push the boundaries of shading language power. Whether you are a developer utilizing Slang in your projects, a contributor helping to shape its future, or simply an enthusiast following our progress, your support and engagement are invaluable to us.

Stay tuned for more updates, and be sure to explore the new features and resources we have introduced. Together, let’s unlock the full potential of Slang and create amazing graphics experiences across diverse platforms.

Thank you for being a part of the Slang community!

Using Slang with Vulkan

Sat, 31 Aug 2024 10:00:00 +0000

Towards a Next-Generation shading Language: Our Journey with Slang

Mon, 05 Feb 2024 10:00:00 +0000

Slang Shading Language Advances

Mon, 05 Feb 2024 10:00:00 +0000

Differentiable Slang: A Shading Language for Renderers That Learn

Sun, 22 Oct 2023 10:00:00 +0000

Shader Slang

Shading Languages Symposium

Shading Language Symposium

SIGGRAPH 2025 Materials Now Available: Recordings and Resources from Our Events

Hands-On Class: Introduction to Slang

Birds of a Feather: Developing with Slang

Neural Shading Course

Getting Started with Slang: Automatic Differentiation

Getting Started with Slang: Automatic Differentiation

Presentations

Automatic Differentiation

Graphics Programming Conference 2025

Getting Started with Slang: Modularization

Slang at SIGGRAPH 2025

Hands-On Class: Introduction to Slang

Birds of a Feather: Developing with Slang

An Introduction to Neural Shading

Latest Slang Release

Language Enhancements and New Functionality

Compiler Architecture Improvements

Improvements to Code Generation, Debugging, and Platform Support.

Language Server Improvements

Can’t Make It to SIGGRAPH?

Looking Forward

Slang: Using AI coding assistants

Introduction

Usage

Getting Started with Slang: Modularization

Modules & Visibility Control

Compilation Pipeline Magic

Specialization Without Preprocessor Pain

Generics vs Templates: The Slang Way

Prerequisites

Speaker

Neural Graphics: Speeding It Up with Wave Intrinsics

Recapping the 2D Differentiable Gaussian Splatting Example

The diff-splatting Approach: A Straightforward Staged Pipeline

balloted-splatting: Harnessing GPU Wave Intrinsics

The Performance Payoff

Looking Ahead

Getting Started with Slang: Reflections API

Slang at HPG 2025: Bridging Graphics and Machine Learning with Automatic Differentiation

Why This Matters

Join Us at HPG 2025

Can’t Make It?

Getting Started with Slang: Reflections API

Prerequisites

Speaker

Getting Started with Slang: Draw Your First Splat

Getting Started with Slang: Draw Your First Splat

We’ll cover everything you need to get started

Prerequisites

Speakers

Neural Graphics: From First Principles to Performance

A More Efficient Algorithm

Tile-based Rasterization with Workgroups

Differential Propagation and Intermediate Value Storage

Local Index Mapping

Results

Welcome Our Newest Slang Committers!

Meet Our New Committers

fairywreath

juliusikkala

Why Committers Matter

Join the Slang Community

Neural Graphics in an Afternoon

Example: 2D Gaussian Splatting

The Challenge: Computing Gradients

The Code

Now Available: Matrix-vector operations using tensor cores

Code Examples

Slang Development Update - January 2025

Documentation Update: Reflection API

Slang Support Now Available on Godbolt Compiler Explorer

Slang and the 3D Shading Language Landscape

Khronos Hosts Open Source Slang Shading Language and Compiler

There’s a lot going on with Slang!

Slang: Now a Khronos Open-Source Project!

Metal Support

WebGPU Support

The `diff-splatting` Approach: A Straightforward Staged Pipeline

`balloted-splatting`: Harnessing GPU Wave Intrinsics