I’ll probably always remember 2025 as the year that I stopped being able to have conversations about future directions for GPU programming without someone slipping the word “neural” into the conversation. While I’m personally skeptical about many applications of neural networks, 2025 is also the year that some really interesting use cases, specifically around realtime graphics, gained attention.

The rise of “neural rendering” (a term I loathe) defined 2025 and dominated the conversation around HLSL this year, but it isn’t the only thing happening in HLSL-land. So let’s talk about the other things first then come back around.

Status of HLSL in Clang

The HLSL teams at Microsoft and Google have continued to make steady progress on the Clang implementation of HLSL. Clang now supports [RW]Buffer and [RW]StructuredBuffer resource types and will soon support [RW]ByteAddressBuffer. The team has continued expanding support for the HLSL intrinsic functions, and we’re just starting work on graphics shaders which will include support for shader inputs and outputs, matrix data types, texture resources and more!

Most of the work that we’re driving is just to bring feature parity with DXC, but I do want to highlight a few areas where we’re investing in significant improvements over DXC.

Better Root Signature Diagnostics

One of the really cool things that got built this year in Clang is the new root signature parser (shout out to Finn Plummer who did this). We get a lot of complaints about root signatures for a lot of reasons, and the weird grammar parsing is just one of the reasons people tend to dislike them. While a longer-term solution to root signatures isn’t currently on our roadmap, the new parser in Clang is pretty awesome and it really shows the kind of quality focus our team is driving.

A key goal of this work was to prioritize great diagnostics coming from the root signature parser with accurate source locations so that if you make a mistake in a root signature the parser will give you as much help as we can to find the error. To enable this, the new root signature parser uses Clang’s utilities for parsing, source locations and diagnostics. This makes it possible for Clang to give diagnostics with accurate source locations in cases where DXC could not.

For example, given the root signatures specified as:

#define BasicValidation \
  "StaticSampler(s0, maxAnisotropy = 13)," \
  "StaticSampler(s1, maxAnisotropy = 17)," \
  "StaticSampler(s2, maxAnisotropy = 13)," \
  "StaticSampler(s3, maxAnisotropy = 13)," \
  "StaticSampler(s4, maxAnisotropy = 23)," \
  "StaticSampler(s5, maxAnisotropy = 13)"

DXC provides the following diagnostic, where the source location points to the line that the preprocessor directive begins on, not necessarily where the error is.

<source>:40:9: error: root signature error - Static sampler: MaxAnisotropy must be in the range [0 to 16].  17 specified.

The new parser in Clang provides much more context, with specific locations inside the macro definition itself:

<source>:42:4: error: value must be in the range [0, 16]
   42 |   "StaticSampler(s1, maxAnisotropy = 17)," \
      |    ^
<source>:45:4: error: value must be in the range [0, 16]
   45 |   "StaticSampler(s4, maxAnisotropy = 23)," \
      |    ^
2 errors generated.

You may notice that Clang produced two errors rather than just one. This is another key difference between DXC and Clang’s parsers. The DXC parser aborts on the first error it encounters. This means that if your root signature has multiple errors you need to iterate resolving one then recompiling the shader to see the next error. The new parser in Clang recovers from parsing errors where it can and attempts to continue parsing to provide a more comprehensive set of diagnostics in a single pass.

To demonstrate some of the resilience in Clang’s parser and it’s ability to recover consider the following root signature that has multiple errors, sometimes in the same clauses:

#define Recovery \
  "CBV(b0, reported_diag, flags = skipped_diag)," \
  "DescriptorTable( " \
  "  UAV(u0, reported_diag), " \
  "  SRV(t0, skipped_diag), " \
  ")," \
  "StaticSampler(s0, reported_diag, SRV(t0, reported_diag)"

For this root signature DXC’s parser provides the diagnostic:

<source>:63:9: error: root signature error - Unexpected token 'reported_diag'
#define Recovery \
        ^

Meanwhile Clang’s new parser identifies multiple errors in a single pass:

<source>:64:12: error: invalid parameter of CBV
   64 |   "CBV(b0, reported_diag, flags = skipped_diag)," \
      |            ^
<source>:66:14: error: invalid parameter of UAV
   66 |   "  UAV(u0, reported_diag), " \
      |              ^
<source>:69:22: error: invalid parameter of StaticSampler
   69 |   "StaticSampler(s0, reported_diag, SRV(t0, reported_diag)"
      |                      ^
<source>:69:45: error: invalid parameter of SRV
   69 |   "StaticSampler(s0, reported_diag, SRV(t0, reported_diag)"
      |                                             ^
4 errors generated.

Clang’s parser can’t always detect all the errors as the parsing context may be incomplete, but it does a much better job than DXC’s parser.

We really think this kind of quality-of-life improvement will make Clang a much better tool for our users and we’re really excited to see some of this quality focus coming to life. Both of the examples above I pulled from a Compiler Explorer demo Finn created that shows off the differences in diagnostics between Clang and DXC really well. Take a look at that for more examples and keep playing with it.

Offload Test Suite

Another big area that we’ve been investing in is our testing infrastructure. DXC’s infrastructure for testing shader execution only supports DirectX on Windows, which turns out to be a pretty big limitation as we’re increasingly viewing HLSL as a cross-platform language. Further, the infrastructure is very tightly connected to DXC in a way that doesn’t make it easy to use with Clang.

To address these limitations we’ve built a new testing infrastructure in LLVM called the Offload Test Suite. The new infrastructure is dependent on LLVM for some utilities, but the test execution is decoupled from the compiler and source language allowing us to run the same tests with DXC and Clang. Additionally, the new infrastructure supports DirectX, Vulkan and Metal giving us wide testing coverage.

We’re using this new infrastructure to not only expand our testing of the Clang compiler implementation, but also to ensure that shaders compiled with Clang behave the same as when they are compiled with DXC. We hope this will make it a smoother migration path for our users.

If you’re interested to learn more about this infrastructure, I gave a talk last fall at the LLVM Developer Meeting about it and how the HLSL team has integrated it to our workflows.

Standardizing HLSL!

Note: I wrote about standardizing HLSL on the DirectX blog. If you prefer to read a more “official” (read humorless and devoid of personality or memes) version of this go there. Otherwise strap in!

The development in HLSL that I’m most excited about coming into 2026 is that we’ve started the process of forming a committee to standardize HLSL. I’ve built my career around open source software, and deeply believe that some types of software just should not be proprietary, moving to standardize HLSL is the only path I see forward for HLSL to evolve and thrive. I’ve said this a few times, but I’ll reiterate it here: the future of HLSL is cross-platform and open.

This has been a huge effort for me personally as I’ve been working to win hearts and minds across Microsoft as well as strengthening partnerships across the industry. Microsoft has some reputations that we’re working to overcome and I’ve put a lot of my personal reputation out to signal that we’re serious about this.

Why are we doing this?

In my experience, compilers and programming languages are just too complicated and don’t bring enough differentiating value for businesses to justify adequately staffing compiler teams to build proprietary compilers at quality and scale that compete against open source alternatives. This is especially true for languages as complex as C++ (which HLSL is trending toward).

Inadequate staffing for HLSL has been a huge problem for our team. We have a massive pressure to constantly expose new shader model features, and we have never had a large enough team to both expose new hardware features and evolve HLSL itself to make users more productive. This has led to a lot of short sighted decisions along the way. We’ve taken shortcuts and accrued massive technical debt, the most obvious bit of which is DXC being locked to LLVM 3.7 which is now over a decade old.

The bare truth is that a good programming language and compiler is price of admission for a platform, but it isn’t going to sell more hardware or software licenses. That said, a bad programming language or compiler can burden software developers so much that it impairs their ability to ship quality software, which will adversely impact sales.

While I don’t think the HLSL compiler is (yet) out of date and “bad” enough to be a real liability, it is trending that direction so we really need to fix it, and in fixing it we need to shift our development model for HLSL to be more sustainable with reasonable investment of resources.

This is all business speak for: embrace open source, build broad partnerships, and build a healthy community.

What benefit will a standard provide for users?

Being unable to invest sufficiently in evolving HLSL itself and in quality toolchain features has contributed to some long-lasting industry problems that have at times seemed intractable. One clear example is the complexity of shader build pipelines.

When you build a cross-platform application’s CPU code you can generally use the same language (and often compiler) for the bulk of your application logic. Concretely, if you’re building a game for Windows, Linux, macOS, Xbox, Playstation and Nintendo; you can write your CPU code in C and C++ and you can use Clang as the compiler. You may have some platform-specific bits in your C/C++ code, but most of the code is easily shared. The same is not strictly true for GPU programming.

The Khronos Group, through its members and community, has done amazing work building a cross-platform pipeline for GPU programs, but it is immensely complex. Consider my modified version of the SPIRV ecosystem diagram from Khronos, where I’ve added DirectX into the picture:

It’s impressive how many source languages you can choose from (on the left), and how many target runtimes you can execute on top of (on the right). The problem is the number of (lossy) translation layers in the middle. SPIRV-Cross in particular is load-bearing in a lot of shader build pipelines, and it destroys debug information (mapping of final executable code to source lines), which makes shader debugging and profiling extremely difficult.

The absence of unifying tooling which led to this ecosystem state has caused cross-platform game engines to develop their own complex shader build pipelines. I’ve been working in this space a long time and I still get horrified when I hear about how developers actually build shaders for their titles.

Shader build pipelines for AAA engines are complex Rube Goldberg machines that we all put up with in the name of maintaining productivity. Microsoft will not sell more XBoxes or Windows licenses if we fix this problem, so the problem gets ignored… Until now.

Today we already have a native build pipeline for HLSL using DXC and Clang to build shaders for DirectX and Vulkan. We also have a native-ish path for Metal through the Metal Shader Converter, which is an IR->IR translator that preserves accurate debug information and enables HLSL to be used with Apple’s native shader debugging and profiling tools (which is crazy impressive!).

My sincere hope is that by standardizing HLSL in conjunction with our integration of HLSL into Clang we’ll build a broad community around HLSL that prioritizes cross-platform support, high quality tooling, and language evolution. Our ultimate goal is to build broad industry partnerships to ensure that all HLSL users get the best tooling possible.

Hey Apple, Sony and Nintendo: come join us!

Don’t standard committees make things slow?

In conversations I tend to use the term “deliberate” to describe how I would like to see HLSL evolve. Historically, I think we’ve allowed the language to evolve haphazardly without a framing process that required us to think through the short and long term implications of new features. We’ve at times moved too slowly and at other times moved too fast. This both leaves us behind in terms of useful feature sets and lacking in quality. As a notable example, HLSL 2021 introduced more bugs than features, and we’ve now spent years addressing them.

I believe that adopting a standard process will force us to evolve HLSL within a process designed to make us be thoughtful and deliberate about the features we add (and remove) from HLSL. This process may at times be slower than we could be without it, and it may be slower than other competing languages, but I believe it will produce a higher quality result which is in the best interests of everyone. I also believe that by doing this under an international standardization body, we will have a framework to keep us honest and curtail our base instincts that may lead us to make rapid and flawed decisions.

I bristle when I hear people talk about “rapid innovation” in programming languages or compilers. There are certainly types of software where rapid innovation may benefit users, but infrastructural software that people depend on needs a level of stability and reliability that is at odds with the “move fast and break things” model.

I can’t imagine anyone wants to integrate an experimental tool in a load-bearing capacity to a production codebase, and following on from that I believe that most of HLSL’s users want to be able to depend on HLSL being stable so that the code they write in HLSL today will work as expected in the future. The worst thing we could do is make fundamental changes to the semantics of HLSL without considering our users and the impact on them, and a standard process will provide a forum for our users to have a voice and a framework to keep us honest as we evolve HLSL for the future.

Okay, how does this really work?

The newly formed Technical Committee 57 under Ecma International will focus on specifying and standardizing the core HLSL language. This effort will focus initially on core behaviors (grammar, basic data types, conversion rules, overload resolution, etc) and a limited set of common features that are across all API targets.

As the committee evolves we hope that it will provide energy around evolving HLSL into a better language while also solidifying it as a cross-platform standard that is not locked to Microsoft platforms.

The committee will operate almost entirely in public and on GitHub, but meetings will only be open to Ecma members and invited experts. We invite everyone to follow along with our public work and contribute to the process!

Neural Rendering

I guess I’ve delayed talking about “Neural Rendering” enough and I should just get this over with. Personally I hate this term because I’m constantly fighting with people to explain that from a compiler and language perspective “neural rendering” isn’t any different from any other neural network evaluation, and it’s all just linear algebra on big multi-dimensional matrices… but alas I’m just an old man yelling.

We do have some big work from last year and ongoing around neural network evaluation. Last year we released a preview of the D3D12 Cooperative Vector feature which enabled evaluation of small neural networks in rendering and compute workloads. After a great deal of soul searching in the fall we decided the feature wasn’t quite ready for primetime, but we’ve been actively working on bringing the capabilities of Cooperative Vector, as well as a more capable replacement for Wave Matrix (which we previewed back in 2023 but didn’t release in SM 6.8).

The new feature, boringly named Linear Algebra (or LinAlg for short) includes both the features of Cooperative Vector, and the features of Wave Matrix. We’ve worked to align the feature more closely with other APIs (read Vulkan) so that our new feature can someday be used with both Vulkan and DirectX via HLSL (and maybe Metal too if Apple aligns). This will enable WebGPU to use it to implement their proposed Subgroup Matrix feature for browsers on Windows.

Regardless of how you feel about GenAI or LLMs (I’m a skeptic), it is clear that neural networks have more and more useful applications in graphics programming. There’s a lot of excitement about neural networks for texture compression, radiance caching, path tracing, denoising, and upscaling. For all these applications and more it’s super important that HLSL be able to efficiently lower these algorithms so that shader authors can take full advantage of modern GPU hardware.

One thing I’m excited about is the capability of neural networks to approximate complex functions. In a few years when matrix multiplication and accumulation hardware trickles down to lower-end GPU parts and proliferates across install bases, function approximation may be a valuable technique for enabling higher fidelity rendering techniques on lower-end hardware at acceptable frame rates.

Parting Thoughts

If you made it this far: congratulations! I’ve droned on a lot and I won’t keep you long here. There are a few key themes I’m pushing for HLSL in 2026 which I’ll state clearly even though they are represented in all the text above.

Cross-platform and Open

The future of HLSL is cross-platform and open. That means open source, it means an open specification with a royalty-free patent and IP policy. It means we will welcome contributions from everyone everywhere.

Quality, Quality, Quality

We cannot sacrifice quality for expediency or flashiness. We’ve been burned time and again by shortcuts and lax quality standards, and that pain spreads to our users. We’ve worked really hard to bring a higher standard of quality to everything we do in HLSL whether that is our compiler implementation, our designs for new features, or our draft language specification. We will continue making those investments in quality, and we will continue to have communities to help keep us honest along the way.

HLSL Exists to Serve Users

The thing that makes HLSL a valuable piece of technology is how widely used it is. We will focus on engaging with our users, responding to their feedback, and prioritizing their concerns. We won’t always give each individual user all the things they want because we do have to take a more wholistic look across our whole user base, but our central motivation must be to empower our users to be productive and to leverage our tools to make their applications the best they can be.

Disclaimer: having an officially supported way to print strings would be super useful for HLSL… Although this isn’t official, this is just me playing around on my holiday break. It is likely we could make something like this supported in Clang, however there are some challenges to supporting this in DXC and when targeting SPIRV or Metal (more on that later).

Before I go any further, let me show you want it looks like to use this. Given the HLSL code here:

 #include "dx/printf.h"

[numthreads(16,1,1)]
void main(uint3 TID : SV_GroupThreadID) {
  // Required to initialize the debug output stream.
  dx::InitializeDebugStream();
  uint idx = TID.x;
  uint value = idx + 1;
  if (value % 3 == 0 && value % 5 == 0)
    dx::printf("FizzBuzz(%u)\n", value);
  else if (value % 3 == 0)
    dx::printf("Fizz(%u)\n", value);
  else if (value % 5 == 0)
    dx::printf("Buzz(%u)\n", value);
  else
    dx::printf("Baz(%u)\n", value);
}

This results in producing a buffer, that when interpreted by the CPU prints (note ordering of messages can be dependent on compiler optimizations and hardware constraints, but more on that later):

FizzBuzz(15)
Fizz(3)
Fizz(6)
Fizz(9)
Fizz(12)
Buzz(5)
Buzz(10)
Baz(1)
Baz(2)
Baz(4)
Baz(7)
Baz(8)
Baz(11)
Baz(13)
Baz(14)
Baz(16)

The Challenges with printf

There are two different classes of challenges that printf pose. First is the general problem space around printf on a GPU, and the second is more about how to fit printf into HLSL. The design I’ve prototyped tries to address problems in both of these spaces to provide a powerful solution for users.

Problem Space: Printing Text on GPUs

The main problem with printing text on GPUs comes down to two main issues around string data: (1) string data can be big, and (2) string formatting is wildly divergent.

Large amounts of string data coming on and off the GPU would pose a significant performance problem at multiple levels of the software stack. Embedding strings into GPU programs bloats the program sizes, increasing the data drivers need to manage and (if not stripped) results in transferring more data than necessary to the GPU (and potentially back). This would result in logging having a potentially massive impact on the runtime of a given shader, which would in turn limit its usefulness as a debugging tool.

Formatting strings on a GPU opens another massive can of worms because thread-divergent values would likely cause significant divergence in processing, and that’s before you even start to think about problems with memory allocations. I don’t know of any implementation outside the “C++ on your GPU” world that has actually tried to do string formatting on a GPU for good reason.

The solution I’ve prototyped aims to address both of these challenges by not doing any string processing on the GPU, and removing the strings entirely from the compiled shader binary that gets handed to the driver. This has an added benefit that it requires no changes to GPU drivers, and can work on existing production drivers.

Instead of processing the strings in the shader program, this solution depends on a new compile-time feature I’ve prototyped in the DirectXShaderCompiler and Clang, which collects all the strings in a shader into a packed de-duplicated string table, and converts strings to offsets into the table via a compile-time evaluated builtin function (__builtin_hlsl_string_to_offset).

With these features printf is entirely implemented in HLSL. The actual implementation from my prototype is:

template <typename... T> void printf(string Str, T... Args) {
  uint ThreadIndex = WavePrefixSum(1);
  uint ThreadCount = WaveActiveSum(1);
  uint StrOffset = __builtin_hlsl_string_to_offset(Str);
  uint ArgSize = NumDwords<T...>() * 4;
  uint MessageSize = sizeof(MessagePrefix) + (ThreadCount * ArgSize);
  uint StartOffset = 0;
  if (WaveIsFirstLane()) {
    InterlockedAdd(OutputOffset, MessageSize, StartOffset);
    MessagePrefix Prefix = {ThreadCount, StrOffset, ArgSize};
    DebugOutput.Store<MessagePrefix>(StartOffset, Prefix);
  }
  StartOffset = WaveReadLaneFirst(StartOffset);
  uint ThreadOffset =
      StartOffset + sizeof(MessagePrefix) + (ThreadIndex * ArgSize);
  StoreArgs(DebugOutput, ThreadOffset, Args...);
}

This function writes into a RWByteAddressBuffer the number of threads participating in the print, the offset of the format string, and the size of the per-thread argument lists. It then writes the per-thread argument list. Each argument takes one or more 32-bit dwords, The current implementation does mis-align 64-bit types, because I’m lazy, and there are a few other missing features and improvements that I’d want to include if we pursued a solution like this in the future.

Problem Space: HLSL isn’t ready (yet)

You may have noticed from the code above that this uses a feature of C++ that doesn’t exist in HLSL (yet): variadic templates. Argument packing for printf is an interesting problem. The way that variable argument lists work in C really won’t work on a GPU. It involves packing arguments into effectively an untyped stack-allocated array and walking the array with the format string to determine the types.

For a GPU program we want as much of the packing/unpacking to happen at compile time as possible. Templates are ideal for this since they’re fully resolved early in the compiler at compile time.

Adding variadic template support to DXC turned out to be unexpectedly easy because of how Clang implements new C++ language features. When a C++ language feature does not add incompatibilities with pre-existing language rules and is strictly additive, the Clang maintainers add the feature in all previous C++ language modes, and issue warnings for using the feature in older modes. This means that all the functionality for resolving variadic templates in the AST was already present in DXC. Re-enabling the support required enabling the parsing logic for parameter packs (...), and everything else just mostly worked.

A second problem that I encountered bringing this to DXC was the implementation of the string type. Many users would probably be surprised to know that HLSL does have a string type, it’s just extremely limited in what you can do with it. Today it is used almost exclusively for specifying root signatures in raytracing shaders.

They are effectively static const char * variables in the raytracing subobject, and they’re disallowed in almost every other semantic context. For this I evolved string objects so they can be parameters to functions. They’re still just const char* pointers (I even fixed a few bugs relating to their const-ness), and they’re passed as pointers rather than copy-in/copy-out.

This slight generalization of string handling allows printf to become a fully software implemented feature.

Bringing it Together

The full implementation of my printf prototype for HLSL can be found in my fork of DXC. The main bits of it are the compiler changes to implement __builtin_hlsl_string_to_offset, and the new printf.h.

In addition to the changes in my fork of DXC I’ve also implemented the string format handling in my fork of our test suite.

In a future where this solution becomes generally supported, I would expect to have the HLSL toolchain vend both the HLSL language functionality and a permissively licensed string format implementation that could be used by any application developer. There’s also nothing intrinsic about how the formatting is interpreted to the system, so it is also possible that a developer could use their own formatting logic with their own format specifiers. This could provide a lot of flexibility to users.

One big caveat: as I mentioned at the beginning the ordering of messages is pretty dependent on compiler optimizations and the hardware you run on. You can’t depend on any given ordering since the atomic operations used to grab space in the output buffer doesn’t have strict ordering guarantees and wave scheduling is largely undefined.

Despite that, this proof-of-concept implementation does work today on any retail DirectX 12 driver that supports Shader Model 6.0 or later.

Future Challenges

Bringing this into the core of the HLSL language and compiler has a few roadblocks. The main missing language features are variadic templates, and more general string types. We have had discussions about adding variadic templates as part of the plan to adopt C++11 as the base of HLSL.

The issues around the string type are a bit harder to figure out. The way strings are used in HLSL today is a bit magic and ill-defined. We’ll really need to spend some time documenting and defining the string object and the syntax and semantics of raytracing root signatures to figure out the best way to support this going forward. I believe there is a relatively straight forward path here, but we’ll need to spend some time working on it.

I fully expect that my prototype implementation will work with Clang in the near-ish future as the missing HLSL features are all in progress, but DXC support is a bit trickier. While I’ve demonstrated that it can work in my proof-of-concept implementation, I’ve worked around a few gnarly bugs in DXC to do so. DXC does some very strange things during codegen for function parameters, that needed to be reverted back to the original Clang code. This makes my prototype work, but causes some of our other tests to fail and I haven’t had a chance to investigate.

There are also some limitations in the current DXC implementation around how format strings can and can’t be used, which may be more restrictive than we really want, and I’d like to at least consider alternatives. Specifically, the current implementation requires that format strings be uniform across all threads, and there might be value in allowing them to be thread-divergent. DXC also doesn’t really support creating local variables of string types, which means you can’t have more general logic to select format strings. Enabling some of these cases will also require that the string lowering IR pass I wrote gain some complexity as well.

I’ve also thought about a slight adjustments that we may want to consider. The current printf implementation depends on a groupshared uint for the counter. We could instead support the counter being the first four bytes of the RWByteAddressBuffer this has a potential benefit that the resulting resources would contain the total amount of data written to the buffer and it saves 4 bytes of groupshared memory, but would be slower during execution. My gut feeling is that stealing 4 bytes of groupshared memory is better, but we could make the implementation work both ways.

Another big area that I haven’t thought about much is how to bring this to Vulkan and Metal shaders. One nice thing about the DirectX object file format is that it has named sections, so the string table can be its own section that the runtime and tools see but is never passed to drivers.

SPIRV has no such separation. To support this in SPIRV we’d likely need to create an annotation instruction that contains the string table and parse the string table out of the SPIRV. Not really a big deal, but unfortunate.

For Metal there are a couple different approaches we could take. One would be to tie this into the Metal logging system. If we wanted to have a unified portable system we’d need some way to attach the string table into the Metal library, or carry the data alongside the shader. This is not the only case where we’re needing to carry side-metadata along with shaders for Metal, so we may need to think more generally about this problem in the future. If only the Metal Shader Converter were open source, then we could make the string table a user-defined attribute on the shader, but alas…

Looking back, 2024 was a big year for HLSL. Shader Model 6.8 went retail, a Work Graphs Mesh Nodes Preview was released, the DXIL Validator was open sourced, DirectX announced plans to adopt SPIRV, and in news you probably missed: simple HLSL shaders compiled with Clang built from main, successfully ran on GPUs for the first time!

That last milestone probably mostly escaped notice, but it was a really huge achievement and I want to take some time to explore the state of HLSL in Clang to show some of the great things that we’re working on right under your nose that you might not be aware of.

Status of HLSL in Clang

Today we have a handful of extremely simple HLSL compute shaders that compile successfully in Clang. Clang supports the basic syntax and semantics of HLSL, a reasonable sampling of the HLSL intrinsic functions, and a couple basic resource types. Clang is not nearly ready for use by developers, but we’re a few weeks away from compiling compute shaders from an internal trove of production code.

Despite the early state of the compiler there are a few improvements over DXC that we can already demonstrate.

Addressing Design Bugs

DXC has a significant number of bugs that exist because either the design of HLSL or design decisions made during DXC’s implementation. In some cases, like the HLSL 202x Conforming Literals feature, we can fix the issue in DXC and implement the correct solution in Clang. In other cases, the fixes in DXC are very complicated and would require invasive changes to DXC.

For an example of the later case consider DXC issue #4871. This issue occurs because of problems in DXC’s design for implementing HLSL’s by-value calling convention. In Clang, we’ve prioritized full and accurate AST representations which enable us to handle these problems more robustly.

Improved diagnostics

HLSL has a lot of implicit behavior which it has carried from its origins as a domain-specific language. Users have found it useful to be aware of implicit behavior, like implicit conversions, since they can have a runtime performance impact. Unfortunately DXC doesn’t always have the ability to diagnose implicit conversions because they are not captured in the AST.

In the example below, Clang will warn about the implicit conversion of F from a float4 to an int4 and the implicit conversion on return of the int4 back to the float4. Meanwhile DXC will perform the conversions with no diagnostics.

void SillyTrunc(inout int4) {}

export float4 Trunc(float4 F) {
    SillyTrunc(F);
    return F;
}

Compiler Explorer

Language Server

Clang comes with a production implementation of Language Server Protocol which is used to power IDE tooling through a JSON-RPC interface that is widely adopted by a large number of code editors.

In our efforts to add HLSL support to Clang we’ve also gained a working LSP server with minimal investment. We plan to continue working on QoL improvements to make clangd’s HLSL support production ready, but even with our minimal investments we’re already seeing promising results!

Experimental Language Features

As we’re working on Clang we’re also not ripping out all of C++’s features. We’ve been leaving C++ features that we want to add to HLSL working in Clang. This simple shader utilizes both C++’s auto keyword and C++ lambdas. Clang can successfully compile this to valid DXIL!

RWBuffer<int4> In : register(u0);
RWBuffer<int4> Out : register(u1);

int reduceSum(int4 V) {
    auto R = [](int LHS, int RHS) -> int {
        return LHS + RHS;
    };
    return R(V.x, R(V.y, R(V.z, V.w)));
}

[numthreads(8,1,1)]
void main(uint GI : SV_GroupIndex) {
    Out[GI] = reduceSum(In[GI]).xxxx;
}

Compiler Explorer

Another frequently requested feature in HLSL is C++’s constexpr. In Clang, we’re using constexpr as a vital implementation tool to ensure constant evaluation of complex math operations. We’re extending constexpr support in Clang to include HLSL’s vector types and implicit conversions so that HLSL expressions can fully leverage the feature. For example the HLSL D3DCOLORtoUBYTE4 function is implemented as a constexpr:

constexpr vector<uint, 4> D3DCOLORtoUBYTE4(vector<float, 4> V) {
  return V.zyxw * 255.001953f;
}

This evaluation includes the implicit scalar to vector conversion and the evaluation of the vector constant expression.

Language Evolution

Something else that happened in 2024 that may have escaped notice was the first approved and implemented feature for the next version of HLSL.

HLSL 202x

The next version of HLSL is codenamed 202x, and it will serve as a bridge between DXC and Clang. We’re realistic that the two compilers will never be fully identical, but 202x will allow us to move DXC toward Clang and Clang toward DXC. This gives us the ability to deprecate some problematic features of HLSL during the compiler transition while providing a graceful path for users. We expect that shaders which compile successfully with HLSL 202x in DXC will compile successfully in Clang with little to no adjustment required.

The first feature added in HLSL 202x was 0017 Conforming Literals, which addressed a number of bugs in DXC that were caused by the complicated way DXC assigned types to integer and floating point literals.

HLSL 202y

In addition to planning our bridging release, we’ve also been planning our next feature release, codenamed 202y, which will be available only in Clang. We expect HLSL 202y will be a combination of new features and refinements of existing HLSL.

As an example, two likely HLSL 202y features are const non-static member functions, and non-member operator overloading. Both of these features require significant changes to how and when overload resolution occurs in HLSL. These features will necessitate adopting overload resolution rules more like C++, which will break source compatibility for some code.

Another feature that has been frequently requested is C++ constructors, which will require addressing our initialization list handling.

While we expect that these features will cause some disruption to existing HLSL codebases, we believe all of these features will deliver on highly demanded user requests, while improving the familiarity of HLSL. The disruptive refinements to the base language will also enable us to add other frequently requested features like union types, conversion operators, and access specifiers.

Public Design Process

One last big change that we were working on at the end of 2024 and are just getting rolling in 2025 is an expansion of our public language design process.

We’ve had difficulty ensuring that proposals move through the process smoothly. We also have found that we need a wide variety of input in order to maintain high quality for all our design specifications. To address both of these issues we’ve started hosting regular public design meetings.

This provides a tactical forum for us to coordinate shepherding proposals through the language evolution process, and it allows us to have a space to discuss changes with a wider audience of stakeholders. We’re optimistic that these public meetings will help us drive a more open and public collaboration to evolve HLSL.