Diligent Engine: one graphics front end across six backends

An abstraction layer rather than an engine in the game engine sense

The project describes itself as a lightweight, high-performance graphics API abstraction layer and rendering framework for cross-platform development. That wording is doing real work, and it is worth holding on to. There is no scene graph here, no asset pipeline, no physics, no entity system. It is the layer that sits between renderer code you write and the native graphics API of whichever machine you are targeting.

The modern tier is Direct3D 12, Vulkan, Metal and WebGPU. Behind it the project keeps the older paths alive, Direct3D 11, OpenGL, OpenGL ES and WebGL, so a single codebase can still cover hardware and browsers that never get the newer API. The licence is Apache 2.0, with `License.txt` at the repository root, which is the permissive end of the scale and matters if you intend to ship the layer inside a commercial engine.

One oddity worth knowing before browsing the code: GitHub reports the dominant language of this repository as Batchfile. That is the heuristic reacting to the batch scripts at the root, not a statement about the implementation. The API names in the release notes, things like `IRenderDevice::CreateShader` and the `ShaderCreateInfo` struct members, are C++ symbols, so the language breakdown tells you nothing useful about the codebase here.

Reading the platform matrix and its numbered footnotes

The centrepiece of the README is a table that crosses eight platform rows against six API columns, plus a build status column. Windows carries D3D11, D3D12, OpenGL and GLES, Vulkan and WebGPU. Universal Windows carries only D3D11 and D3D12. Linux carries OpenGL and GLES, Vulkan and WebGPU. Android carries OpenGL and GLES and Vulkan. macOS is the widest row, with OpenGL and GLES, Vulkan, Metal and WebGPU. iOS carries OpenGL and GLES, Vulkan and Metal, tvOS carries Vulkan and Metal, and visionOS carries Metal and nothing else.

Two things follow from reading it closely. Direct3D appears in exactly two rows, Windows and Universal Windows, so this is not a way to share Direct3D 12 code with a Mac. And the smaller platforms are narrow: a single filled cell for visionOS is not a rounding error, it is the actual support surface.

Several cells carry numbered footnotes, marked 1, 2 and 3. The README does not reproduce the legend that explains them, so treat those as qualified support rather than a plain yes. What the table does settle is the CI layout, because each row links a build status badge and the workflow names in those URLs are build-windows.yml, build-linux.yml, build-android.yml and build-apple.yml. Alongside that sits an Appveyor badge at the top of the README and an `appveyor.yml` in the tree, which points to a second and older pipeline.

HLSL as the shared shading language, native formats behind it

The README states the arrangement plainly: a consistent front-end API, HLSL as the universal shading language, and support for the platform specific shader formats GLSL, MSL, DirectX bytecode and SPIR-V for optimised performance. Read that as direction of travel. GLSL and MSL are outputs, not inputs. You author HLSL once and the layer handles the translation per backend.

That design is what the v2.5.4 release notes feed into. They list shader constant buffer reflection among the API improvements of that release, and they add a `ShaderMacroArray` struct so that the `Macros` member of `ShaderCreateInfo` changes type. Reflection is what lets the engine discover a shader's bindings, and the macro array is how one shader source gets compiled into several backend specific variants. Those two small changes are the machinery that makes a single shader file portable.

The v2.5.6 notes then add asynchronous shader compilation, which they describe as compiling shaders in parallel. On a renderer with a large shader set, serial compilation at startup is a stall you feel, and this is one of the more concrete reasons to be on a recent version rather than an older tag.

What sits in the four project directories at the root

The tree is short and it divides cleanly. `DiligentCore` is the abstraction itself. `DiligentFX` holds the higher level rendering components, and the v2.5.5 release notes show what has been landing there: screen-space reflections, screen-space ambient occlusion, depth of field, bloom and temporal anti-aliasing, each in its own directory under a `PostProcess` folder with a media folder beside it. `DiligentSamples` is the tutorial set. `DiligentTools` is the conversion and asset tooling.

Alongside those four the root carries `Doc/`, `Media/`, `Tests/`, `.github/`, `.vscode/`, `CMakeLists.txt`, `.gitmodules`, `.clang-format`, `ReleaseHistory.md`, `Troubleshooting.md` and `appveyor.yml`. Several of those deserve a note. A `.clang-format` means code style is pinned by a file rather than left to argument. A `.gitmodules` means dependencies come in as submodules, which is the usual source of first build trouble. `ReleaseHistory.md` and `Troubleshooting.md` sitting at the root of a library whose API gets renamed between versions is a good sign about how the project handles its own churn.

The release notes link to `DiligentGraphics/DiligentFX` and `DiligentGraphics/DiligentSamples` as project pages under the same organisation, so those directories have their own presence outside this repository.

Three releases: .NET bindings, post-processing effects, WebGPU

The three most recent releases each moved one substantial thing, and reading them in order tells you what the project thinks is important.

v2.5.4, dated 2023-08-08, enabled .NET support. Applications can use the NuGet package `DiligentGraphics.DiligentEngine.Core`, which implements the Core Diligent API, and a tutorial named `Tutorial03_Texturing-DotNet` demonstrates it. The same release did the API housekeeping: read-only depth buffers, texture component swizzle and shader constant buffer reflection as improvements, and a set of removals and renames under numbered API codes. The `ppCompilerOutput` member came out of `ShaderCreateInfo` and became a parameter on `IRenderDevice::CreateShader`, `ShaderCreateInfo::ppConversionStream` was removed outright, and `ResourceMappingDesc` was replaced by `ResourceMappingCreateInfo` with an explicit `NumEntries` instead of a trailing null entry. If you are porting code written against an earlier 2.x, that list is your migration work.

v2.5.5, dated 2024-05-06, filled out `DiligentFX` with the post-processing effects listed above.

v2.5.6, dated 2024-09-02, added the WebGPU backend, which the notes describe as making the web a first-class citizen, and they argue WebGPU over WebGL on four counts: lower CPU overhead, native compute shader support where WebGL has none, a more explicit API, and finer resource management. Compute is the honest reason to care, since the other three are tuning arguments.

Where the README stops and what it does not settle

It is worth being clear about the gaps, because they are the parts you will spend your own time on. The README carries badges, a platform matrix and a description of the shading model. It does not give build instructions, dependency versions, or a way to obtain binaries. There is no package manager recipe in it, no minimum toolchain version, and no mention of a contributor list or a governance model. Everything operational lives behind the documentation link at `diligentgraphics.github.io/docs`, the Discord invite, and the project site at `diligentgraphics.com/diligent-engine/`.

The `Troubleshooting.md` and `ReleaseHistory.md` files at the root are where a reader should look first given that, and the v2.5.4 rename list is a fair warning that API stability is versioned rather than promised across minor releases.

On activity, the last push was on 2026-09-22 and the repository is not archived, on the `master` branch. The newest tag, v2.5.6, is dated 2024-09-02. That gap of roughly two years between the tip and the most recent release is the single most consequential fact for anyone choosing a version, and it is not something the README mentions. There are 24 open issues against that, which is a small number for a project of this age and scope, though the repository is largely a mirror of work whose issues live elsewhere.

Editorial conclusion

The abstraction layer is the whole product here, and the README is unusually direct about what that means: HLSL in, one front-end API, six backends, Apache 2.0. Two facts should drive the decision. WebGPU arrived in v2.5.6 on 2024-09-02 alongside asynchronous shader compilation, and the last push was on 2026-09-22, so master runs roughly two years past the newest tag and a pinned release is not the tip. The README carries no build or install instructions, only a documentation link, a Discord invite and a matrix of supported backends, so the first hour with this project goes into getting CMake, the submodules and a tutorial sample running before anything else. If you already write HLSL and want one renderer across Windows, Linux, macOS and the web, that is the case it is built for.

Frequently asked questions

Official sources

1. DiligentGraphics/DiligentEngine on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases