# DiligentCore: one low-level graphics API over six rendering backends

> DiligentCore is the C++ module that gives Diligent Engine a single device, context and swap chain abstraction over Direct3D11, Direct3D12, OpenGL, OpenGLES, Vulkan and WebGPU. It is self-contained, but its build recipe, its Apple backend and its release tags all raise questions before you adopt it.

**DiligentGraphics/DiligentCore** — A modern cross-platform low-level graphics API

- Repository: https://github.com/DiligentGraphics/DiligentCore
- Website: http://diligentgraphics.com/diligent-engine/
- Stars: 764 · Forks: 191
- Language: C++
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/diligentgraphics-diligentcore

## A narrow C++ layer beneath the Diligent Engine

DiligentCore is written in C++ and sits at the bottom of the Diligent Engine stack. Its job is specific: present one API surface for Direct3D11, Direct3D12, OpenGL, OpenGLES, Vulkan and WebGPU, and absorb the differences between those backends so that calling code does not have to. The project describes it as a modern, cross-platform low-level graphics API that forms the foundation of Diligent Engine.

The phrase low-level carries the important weight here. There is no scene graph, no shading system and no asset pipeline in this repository. What there is, based on the documented API basics, is a device, an immediate context, a swap chain, resources, shaders, pipeline state, resource layout, binding and draw calls. If you are weighing DiligentCore against a complete engine, settle that scope difference first. DiligentCore answers the backend question, and it leaves the engine question to a separate repository.

## The recursive clone is the whole installation story

The repository gives you exactly one command to get the code, and it is the recursive form:

```bash
git clone --recursive https://github.com/DiligentGraphics/DiligentCore.git
```

The flag is not cosmetic. The project ships a .gitmodules entry and a ThirdParty directory, and the build expects those dependency trees to be present inside the working copy. A plain clone leaves them empty and pushes the failure later, into configure or link time, where the error message is less helpful than it would be at clone time.

Beyond that, the build instructions are not in this repository. The project documentation sends you to the build and run instructions in the main DiligentEngine repository, and it also states that the module is fully self-contained and can be built independently of the rest of the engine. The checkout is narrow in scope, but the recipe you need to compile it lives one repository over. Plan to read both before the first build.

## Device, immediate context and swap chain come first

Every API basics path starts the same way. Before any functionality is available, you must create a render device, an immediate context and a swap chain. The initialization documentation covers separate recipes for Win32, Universal Windows Platform, Linux, macOS, Android, iOS and Web, which tells you that device creation is platform-dependent even though the objects handed back are not.

The Win32 sample shows how that branching looks:

```cpp
void InitializeDiligentEngine(HWND NativeWindowHandle)
{
    SwapChainDesc SCDesc;
    // RefCntAutoPtr<IRenderDevice>  m_pDevice;
    // RefCntAutoPtr<IDeviceContext> m_pImmediateContext;
    // RefCntAutoPtr<ISwapChain>     m_pSwapChain;
    switch (m_DeviceType)
    {
        case RENDER_DEVICE_TYPE_D3D11:
        {
            EngineD3D11CreateInfo EngineCI;
```

The switch selects the device type, and the D3D11 branch fills an EngineD3D11CreateInfo structure that will carry the adapter selection and the native window handle. After that, the documented order continues through creating resources, creating shaders, initializing pipeline state, describing the pipeline resource layout, binding shader resources, and finally setting the pipeline state and invoking the draw command. Treat that list as a checklist. The API is explicit, and nothing in it is implicit for your benefit.

## Graphics, Platforms and Primitives divide the codebase

The top-level entries describe the shape of the project without needing the source tree open in front of you. Three functional directories stand out: Graphics, Platforms and Primitives, with Common beside them. BuildTools and CMakeLists.txt cover the build, Directory.Build.props and Directory.Packages.props point at a managed build path, ThirdParty holds vendored dependencies, Tests holds the test suite, and doc holds documentation assets. CODEOWNERS and .clang-format sit alongside a .github directory and an appveyor.yml file.

Two filenames earn attention. The .clang-format file at the root means formatting is settled by configuration rather than by taste, which matters if you plan to contribute patches upstream. The CMakeLists.txt file at the root is the configure entry point, and the dotnet-style props files explain how the NuGet packages listed in the documentation are assembled. Expect the folder names to be internal rather than a mirror of the public API, since the interface is described in doc and in the published documentation site instead.

## Metal sits outside the Apache-2.0 grant

Licensing here has a wrinkle the badge alone does not show. The repository is licensed under Apache-2.0, and License.txt sits at the root next to the licence badge. Yet the project documentation states that a Metal backend is also available for commercial clients. That backend is therefore not part of what an Apache-2.0 user receives by default.

The Apple targets in the build status table cover macOS, iOS and tvOS, all built through the Apple workflow. So a team shipping on Apple hardware has a decision to make that a team shipping only on Windows does not: whether the Metal backend is needed, and under what arrangement. Get that answered in writing before committing to the platform, because a backend that is excluded from the open grant cannot be substituted later by a simple build flag change.

The NuGet package build instructions are the other licence-adjacent item worth reading early. They describe a distribution route you may be able to reuse, and they are also where your own packaging conventions are most likely to collide with the project's.

## Releases trail the commits by about two years

Tags and commit activity tell two different stories. The three most recent releases are v2.5.6 from 2024-09-02, v2.5.5 from 2024-05-06 and v2.5.4 from 2023-08-08. The repository is not archived, and the last push to the default branch was on 2026-10-20.

Put those two facts together and the picture is clear. The code is being worked on while the published releases sit roughly two years behind. For a graphics library that gap matters more than it would for a utility, because backend code changes in response to driver and hardware revisions, and anyone pinning a 2024 tag inherits whatever API surface that tag froze. The documentation describes no nightly or rolling package, so the practical choice is between an old tagged release and a moving branch.

ReleaseHistory.md at the repository root carries the version detail, and the release history section of the documentation table of contents is where the project's own changelog narrative lives. Read it before deciding which side of that gap you want to sit on.

## The first hour is spent outside this repository

The honest caveat is visible in the documentation itself. The Win32 code sample is cut off mid-line, and the initialization recipes for the other six platforms appear in the table of contents but not in full text. The practical effect is that adoption starts in the main DiligentEngine repository and in the online documentation, not in the README here.

Three gaps are worth naming explicitly. There is no documented rollback path for a bad upgrade, so plan your own version pinning. There are no performance numbers for any backend, which leaves you without a basis for claiming one is faster than another and without a baseline to detect a regression after you upgrade. And the interoperability story exists only as a table of contents entry titled low-level API interoperability, which is the first thing to read if you already hold a Direct3D or Vulkan device and want to share it rather than replace it.

None of this makes the abstraction a bad bet. It does mean the decision is not whether the API design suits you, it is whether you are willing to track a repository whose newest tag is older than its own branch.

## Conclusion

Adopt DiligentCore if you are writing C++ rendering code that must run on several graphics backends and you want the device, context and swap chain layer handled for you. Do not adopt it if you need a full engine, a Metal backend under an open licence, or pinned releases, because the newest published tag is v2.5.6 from 2024-09-02 while the last push was on 2026-10-20. Before committing, build the recursive clone on your target platform, read the build instructions in the main DiligentEngine repository, and confirm with the project how the commercial Metal backend is licensed.

## FAQ

### Which rendering backends does DiligentCore support?

The project documentation lists Direct3D11, Direct3D12, OpenGL, OpenGLES, Vulkan and WebGPU as the implementations included in the module. A Metal backend is also available, but only to commercial clients.

### How do I build DiligentCore from source?

Clone the repository recursively so the submodules are present, using git clone --recursive https://github.com/DiligentGraphics/DiligentCore.git. The actual build steps are documented in the build and run instructions of the main DiligentEngine repository, since DiligentCore can be built independently of the rest of the engine.

### Is DiligentCore still actively developed?

The repository is not archived and the last push was on 2026-10-20, so commits are still landing. The newest published release is v2.5.6 from 2024-09-02, so the tag you can install is considerably older than the branch head.

### What do I need before I can draw anything with DiligentCore?

You need a render device, an immediate context and a swap chain, created through platform-specific initialization code documented for Win32, Universal Windows Platform, Linux, macOS, Android, iOS and Web. After that the documented flow moves through resources, shaders, pipeline state, resource layout, binding and the draw command.

## Sources

- [DiligentGraphics/DiligentCore on GitHub](https://github.com/DiligentGraphics/DiligentCore)
- [License: Apache-2.0](https://github.com/DiligentGraphics/DiligentCore/blob/master/LICENSE)
- [Project website](http://diligentgraphics.com/diligent-engine/)
- [README](https://github.com/DiligentGraphics/DiligentCore/blob/master/README.md)
- [Releases](https://github.com/DiligentGraphics/DiligentCore/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/diligentgraphics-diligentcore