HLSL was introduced with DirectX 9 as a successor to DirectX Assembly. The original use was for shading programs which enabled customization of GPU vertex and pixel processing.

While HLSL had a C-inspired syntax, the language was originally very much a domain-specific programming language rather than general purpose. HLSL had weak typing and a lot of implicit and weakly defined behaviors to allow a wide array of permissible behaviors improving portability of programs across widely disparate hardware. As HLSL evolved, the language has progressively tightened its definition. It has morphed into a general-purpose programming language and gained features of modern C and C++ along the way.

A pivotal moment in HLSL’s evolution came with the adoption of Clang, the LLVM compiler for C-based languages, as the basis for the DirectX Shader Compiler (DXC) in 2015. This moved HLSL to be more like C and C++, and enabled a wide array of more complex language constructs.

An even bigger shift came in 2017 when Microsoft open-sourced the DXC codebase and shifted much of DXC’s development to GitHub. This opened the door to direct contributions from outside Microsoft, and while we’ve had many such contributions in the years since, none have had quite the lasting impact as the introduction of SPIRV code generation support for Vulkan.

DXC’s SPIRV code generation support was contributed by a team at Google, and they’ve continued to be active maintainers of HLSL’s support for Vulkan (as well as wider areas of DXC) ever since. This partnership expanded in 2021, with Google supporting the implementation of the HLSL 2021 language features, and continued to thrive as the design process for HLSL features moved into a more public space in 2022.

In 2022 we began the process of adding HLSL support to the upstream Clang compiler. This shift from building HLSL in an out-of-date fork to aligning our development with the LLVM project has strengthened existing partnerships and forged new ones. By folding into LLVM’s development processes, we have gained the expertise of the core maintainers of LLVM and Clang, attracted additional contributions from students and enthusiasts, and embraced a collaboration model that makes the HLSL development community stronger and more welcoming.

All this history has shown us the value of building both great technology and great community.

While the HLSL team has been on a journey of opening and building community, the world of shader authoring tools has also evolved. In the early days of HLSL, shaders were often extremely simple, perhaps just a few dozen lines, and all the shaders for a title might only measure in the thousands of lines. Today, individual shaders for AAA game titles can top a million lines of HLSL, and a title can have thousands or even millions of shader variants composed by stitching together smaller bits of shader code. This explosion of shader code compounds problems with shader portability.

For decades, game studios have invested in building complex shader authoring systems with custom programming languages, translation layers, and/or shader preprocessing tools. All this tooling has come into being because there is no one shader language that provides best-in-class experiences across all platforms and graphics APIs. Today with HLSL’s direct code generation to DXIL for DirectX, SPIRV for Vulkan, and Apple’s Metal Shader Converter to convert DXIL to Metal’s AIR, we’ve gotten very close, but the lack of detailed specification and conformance testing for HLSL causes subtle portability problems that can be difficult for users to diagnose and address. Further, ensuring that HLSL has best-in-class support for all platforms and runtimes will require support from platform owners, not just the growing HLSL open-source community.

One key step we believe will help to address this problem is giving platform owners an equal stake in the future of HLSL, and this is what Ecma TC 57 will do. By forming a standardization committee, we enable every organization that wants to have a say in the direction of HLSL to participate with an equal voice to shape the future of HLSL across all platforms. This is a recognition from the HLSL team at Microsoft that HLSL has grown to fill a role that extends beyond the boundaries of Microsoft’s platforms, and a commitment to the industry to continue supporting that expanded role.

When people hear “standardization process,” they sometimes assume it comes as the expense of speed. In practice, we see it differently. For us, standardization is about being intentional—making intentional design choices so developers can build confidence. Over the years, we’ve focused on evolving HLSL in a way that prioritizes stability, clarity and that brings new expressivity and productivity tooling.

The HLSL team has been using a language design process heavily inspired by other successful programming languages like Python and Rust. While this process may not be perfect, we’ve found that spending more time fleshing out design and addressing problems before we encounter them in the wild has resulted in speedier implementation, less re-design cycles, and a higher quality result. We plan to take these learnings with us to our new Ecma Technical Committee.

Ecma International provides a more flexible process for defining standards compared to other standardization organizations. This will allow the new Technical Committee to balance the tradeoffs between stability and evolution and continue to adapt to wider industry trends. The flexibility of Ecma’s process has been tested in the real world with other programming languages like JavaScript and C#, which continue to evolve meeting user needs while also providing the stability necessary to ship production software at scale.

Ecma TC 57 is open to participation by all Ecma members, and Ecma membership is open to any organization and has different fee schedules based on the size of the organization.

In addition to the technical committee, we’re continuing our commitment to an open development process. All proposals and documents for the HLSL specification will be publicly hosted on GitHub. Further, the technical committee will be developing a conformance test suite also freely distributed on GitHub.

Our vision for HLSL is that of a robust open standard enabling productivity and creativity across the widest possible spectrum of hardware and software environments. Our goal is to produce a standard language that our users can depend on for portability to all the places their applications go.