glslang: the Khronos reference front end for GLSL, ESSL and SPIR-V

What glslang actually compiles, and who needs it

glslang is a set of components rather than one program. The README lists four: a reference validator and GLSL/ESSL front end that produces an internal abstract syntax tree, an HLSL front end, an AST to SPIR-V back end, and a reflector API that reads reflection data from the AST rather than from emitted SPIR-V. A standalone command-line wrapper, named glslang, exposes all of it.

The README describes the GLSL/ESSL front end as "virtually complete, with results carrying similar weight as the specifications." That sentence is the whole reason the project exists. When a shader is rejected by a driver and you want to know whether the shader or the driver is wrong, a front end that tracks the specification is a different kind of tool from a vendor compiler tuned for throughput.

The audience follows from that. Engine teams that need a second opinion on shader validity, driver and toolchain engineers, and anyone building a shader pipeline that must emit SPIR-V will find the library useful. Someone who wants to write a shader and see it on screen should look elsewhere; glslang has no renderer and no interactive mode.

Inside the pipeline: source, AST, SPIR-V, reflection

The data flow is stated plainly in the component names. GLSL or ESSL source goes in, an AST comes out, and the back end translates that AST into SPIR-V. Reflection is a separate API that reads from the AST and from the high-level source, not from the final SPIR-V module.

That last detail matters more than it looks. The README says the reflector is accurate for the input HLL and AST but only approximate for what would later be emitted for SPIR-V. In other words, if your tooling asks the reflector what a uniform buffer looks like, you are getting the compiler's view of the source, not a guarantee about the binary you will hand to a driver. For a build-time linter that is fine. For a runtime system that binds resources by reflecting on a compiled module, the approximation is a real gap, and the README offers no specification or completeness goal to measure against.

The HLSL path is a third input into the same AST. It is described as translating "an approximation of HLSL," which is a candid way of saying it was never a full HLSL implementation. The News section states that this front end is deprecated as of April 2026 and will be removed at the next major version, with at least 18 months of notice from the announcement.

Installing glslang and compiling a first shader

The README points to prebuilt binaries first: instead of building manually, you can download binaries for your platform from the main-tot release on GitHub. Those binaries are uploaded by the buildbots after successful testing and reflect the current top of the main branch. If you want a tagged release rather than a moving target, you build from source.

Building needs a C++17 compiler (MSVC 2019 or later on Windows), CMake, make on Linux, and optionally Python 3.x for the SPIRV-Tools scripts. Bison is only needed when changing the grammar, and googletest only when modifying glslang itself. Start by cloning the repository and fetching the external projects:

git clone https://github.com/KhronosGroup/glslang.git
cd glslang
./update_glslang_sources.py

Then configure and build. The README's Linux recipe sets a Release build type and an install prefix inside the source tree:

cmake -B $BUILD_DIR -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX="$(pwd)/install"
make -j4 install

On Windows the same configure step omits the build type, and the install runs through CMake instead of make:

cmake -B $BUILD_DIR -DCMAKE_INSTALL_PREFIX="$(pwd)/install"
cmake --build . --config Release --target install

With the binary on your path, running glslang with no arguments prints a usage statement. Basic operation is to give it a shader file; it prints warnings and errors and optionally an AST. The stage is inferred from the file extension, so a file named shader.frag is treated as a fragment shader and shader.comp as a compute shader. Ray tracing stages use .rgen, .rint, .rahit, .rchit, .rmiss and .rcall. There is also a non-shader .conf extension for a configuration file of limits, with an example in the usage statement.

The README notes that building glslang as a DLL or shared library is now possible and supported, which is the relevant detail if you intend to link the library rather than shell out to the binary.

The HLSL front end is deprecated, and that changes the calculus

The clearest limitation in the project is not a bug. It is a policy decision with a deadline attached. The HLSL front end is deprecated as of April 2026 and will be removed at the next major version of glslang, with at least 18 months of notice from the announcement. Bug reports for it are no longer accepted, and security issues are assessed case by case.

If your build depends on glslang to compile HLSL, the README's own guidance is to maintain a fork at the tag corresponding to the deprecation announcement. That is a significant maintenance commitment, and it is the sort of thing worth discovering before you wire glslang into a release pipeline rather than after. The rationale and migration guidance live in issue #4210, which the README links but does not summarize.

Two smaller traps are worth flagging. First, the --shift-texture-binding option no longer affects combined samplers; the new --shift-combined-sampler-binding option controls combined sampler bindings independently from separate textures, and the old behavior requires setting both options to the same value. Any build script carrying the old flag alone will silently shift less than it used to. Second, the spirv-remap utility has been ported out of glslang into the SPIRV-Tools repository as an optimization pass called canonicalize-ids, available in spirv-opt. Tooling that invoked spirv-remap from a glslang install needs to be repointed.

glslang against shaderc and glslc

The natural comparison is shaderc and its glslc command-line front end. Both compile GLSL, and both can emit SPIR-V, so the difference is not the input language. It is where the code comes from and what the project optimizes for.

glslang is the Khronos reference implementation. Its stated purpose is reference validation, and the README claims results carry similar weight as the specifications. That framing tells you the priority is conformance, not build speed. shaderc is built for integration into larger graphics toolchains, and glslc exists as a compiler driver in the same family. If you want one command that takes a shader and produces a SPIR-V file with sensible defaults, glslc is the shorter path. If you need to know whether a shader is legal per the specification, or you need the AST and the reflector API, glslang is the one that exposes those.

There is also SPIRV-Cross, which people search for alongside glslang. It is not a competitor at the same layer: SPIRV-Cross works on SPIR-V, while glslang produces it. The two sit on opposite sides of the same intermediate representation, and a pipeline that emits SPIR-V with glslang and then translates it onward with SPIRV-Cross is a coherent arrangement rather than a choice between them.

Maintenance, releases and what the licence files imply

The repository is not archived, and the last push was on 2026-09-22, one day before this writing. Release 16.6.0 is dated 2026-09-11, and 16.5.0 is dated 2026-08-03, so tagged releases arrive on a roughly monthly cadence. There is also a main-tot release dated 2023-01-30, which is the rolling buildbot artifact the README tells you to download for prebuilt binaries; note that its release date is much older than the tagged versions even though the artifacts it carries track the top of main.

Upgrade cost is dominated by the two breaking changes above rather than by API churn. Moving past the current major version means losing the HLSL front end entirely, and scripts using --shift-texture-binding need the companion option. The project ships a CHANGES.md at the repository root, which is where those transitions are recorded.

On licensing, the repository carries a LICENSE.txt file, a LICENSES/ directory, REUSE.toml and a license-checker.cfg, and the GitHub metadata reports the licence as NOASSERTION. That combination means the licence is expressed through files in the tree rather than a single SPDX identifier the platform recognized. Read LICENSE.txt and the LICENSES/ directory before you ship a binary, especially if you build the shared library form. This is a description of what is in the repository, not legal advice.

Editorial conclusion

Adopt glslang if you need reference-grade GLSL/ESSL validation or an AST-to-SPIR-V path you can link into a C++17 toolchain, and if you are willing to build from source or track the main-tot binaries. Do not adopt it as an HLSL compiler: that front end is deprecated as of April 2026 and will be removed at the next major version, with bug reports no longer accepted. Before committing, verify which release tag you will pin, whether you can live without the spirv-remap utility that moved to SPIRV-Tools as the canonicalize-ids pass, and whether the reflector's approximate SPIR-V mapping is precise enough for your pipeline.

Frequently asked questions

Official sources

1. Issues
2. KhronosGroup/glslang on GitHub
3. README
4. Releases