# LLGL: a thin C++ abstraction layer over OpenGL, Direct3D, Vulkan and Metal

> LLGL is a low level graphics library that gives one C++11 API across five rendering backends and eight platforms. It is a fit for engine and tool authors who need backend switching without a scene graph, and a poor fit for anyone who wants one.

**LukasBanana/LLGL** — Low Level Graphics Library (LLGL) is a thin abstraction layer for the modern graphics APIs OpenGL, Direct3D, Vulkan, and Metal

- Repository: https://github.com/LukasBanana/LLGL
- Stars: 2,629 · Forks: 160
- Language: C++
- License: BSD-3-Clause
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/lukasbanana-llgl

## The problem LLGL solves for graphics engine authors

Shipping a renderer on more than one platform usually means writing the same draw call several times: once against D3D12, once against Vulkan, once against Metal. Each API has its own resource model, its own command encoding, and its own rules about when a buffer may be written. LLGL addresses that duplication by putting a single C++ interface in front of OpenGL, Direct3D 11, Direct3D 12, Vulkan and Metal, and letting the application select a backend at runtime rather than at compile time.

The audience is narrow and specific. This is a library for people who already know what a command buffer, a render target and a pipeline state object are, and who want to keep writing that code while dropping the per-API plumbing. The README describes the goal as a thin abstraction layer that keeps close coupling with the underlying APIs for a rich feature set while simplifying architectural hurdles. That phrasing matters: LLGL does not hide the GPU. It standardises the vocabulary.

It is not a game engine, and the repository layout reflects that. There is include/, sources/, a wrapper/ directory with C99, C# 6.0 and Go bindings, and an examples/ tree split by language rather than by feature. Nothing in the top level suggests a scene format, an editor or an asset importer. If you need those, LLGL is a layer you would build on, not a replacement for them.

## How the backend abstraction is organised

The library is written mostly in C++11, and the platform support table is the clearest statement of how the abstraction is distributed. On Windows, D3D12, D3D11, Vulkan and OpenGL are all listed as supported. UWP covers D3D12 and D3D11 only. GNU/Linux covers Vulkan and OpenGL. macOS and iOS cover Vulkan, OpenGL and Metal. Android covers Vulkan and OpenGL. Wasm covers OpenGL only.

That table is also the honest description of the cost. A single source tree does not mean a single set of capabilities. Metal is marked N/A on Windows, UWP and Android, and D3D12 and D3D11 are marked N/A everywhere except Windows and UWP. If your product ships on Windows and macOS, you are effectively choosing between Vulkan and OpenGL as the common denominator, or writing per-platform paths anyway.

The wrapper directory is the second structural decision worth noting. C99, C# 6.0 and Go bindings exist alongside the C++ core, which means the abstraction is intended to survive a foreign function boundary. That is a different design constraint from a header-only C++ library: the interface has to be expressible in C, which tends to push toward handles and explicit lifetimes. The examples/ directory mirrors this, with separate C99, CSharp, Cpp and Go trees plus a Shared/ directory for common assets.

One thing the README does not document is what happens when a backend lacks a feature the application requests. There is no described capability-query contract or fallback policy in the README, so the extent to which LLGL smooths over feature differences between backends is not something you can determine from the README alone.

## Installing LLGL with vcpkg and building a first example

The README offers two routes. The first is CMake: build scripts are provided for CMake, and the build notes point to the LLGL Build System documentation in docu/. The second is vcpkg, and the README gives the exact sequence. After the port is installed, vcpkg integrate install wires the library into your toolchain so that a CMake project can find it without manual path configuration.

```bash
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg install llgl
```

The README notes that the LLGL port in vcpkg is kept up to date by Microsoft team members and community contributors, and that if the version is out of date you should open an issue or pull request on the vcpkg repository rather than on LLGL. That is worth reading carefully: the version you get from vcpkg is not necessarily the version described in the LLGL README, which currently documents 0.05 Beta.

For a first real use, the repository ships run scripts at the top level. On Windows there is RunExamplesWin64.bat, on Linux RunExamplesLinux.sh, and on macOS RunExamplesMacOS.command. These correspond to the examples/ tree, whose README is at examples/README.md and whose C++ tutorials are indexed in examples/Cpp/README.md.

```bash
./RunExamplesLinux.sh
```

What you should see is the example binaries launching, including the post-processing, shadow mapping, PBR and cloth physics demos whose screenshots appear in the README. Running an example before writing any code is the cheapest way to confirm that a backend initialises on your machine, because the examples exercise the same device and swap-chain creation path your application will use.

Platform prerequisites are listed separately. Windows needs Visual Studio 2015 or later plus the Windows SDK for the D3D11 and D3D12 backends. macOS and iOS need Xcode 9 or later. GNU/Linux needs the development libraries for X11 and its Xrandr extension. Android needs the NDK at API level 21 or above, and the build script can generate project files for Android Studio.

## Where LLGL is the wrong tool

The most concrete limitation is release cadence. The three most recent releases are Release-v0.04b on 2025-07-08, Release-v0.03b on 2023-09-15 and Release-v0.02b on 2018-08-25. Every one of them is a beta. The gaps are measured in years, not months, and the README's documentation section already points at version 0.05 Beta while the newest tag is 0.04b. If your project needs a versioned, stable ABI with a predictable upgrade path, this is a mismatch, and the last push date on the default branch does not change that: commit activity and tagged releases are different promises.

The second limitation is the platform matrix itself. Because backend availability differs per platform, a cross-platform title that wants D3D12 on Windows and Metal on macOS is not writing one renderer; it is writing two renderers behind one interface. LLGL reduces the amount of code you write per backend, but it does not remove the need to test each backend, and the README gives no automated conformance suite description that would let you skip that testing.

The third case is simpler. If you are building a single-platform application, the abstraction buys you nothing. A Windows-only tool that will only ever use D3D11 gains a dependency and an indirection layer in exchange for portability it does not need. The same applies if you need a feature that only one backend exposes: a thin layer that standardises vocabulary is not the place to reach for vendor-specific extensions, and the README does not describe an escape hatch for that.

## LLGL against bgfx, Magnum and NVRHI

The related searches around this project are dominated by other renderer abstractions, and the comparison is fair, because the choice between them is a choice about how much the abstraction is allowed to hide.

bgfx takes a different position on the shader problem. It ships its own shader cross-compilation toolchain and a shader language that compiles to every supported backend, which means the abstraction extends into your shader source. LLGL, as described in the README, is a C++ API layer with C99, C# and Go wrappers; the README does not describe an equivalent shader translation pipeline, so shader authoring stays your responsibility per backend. If shader portability is your main pain, bgfx addresses it directly and LLGL does not.

Magnum sits closer to a toolkit than a thin layer. It bundles a math library, scene graph utilities and application scaffolding on top of a GL abstraction. LLGL's top-level layout has no equivalent: include/, sources/ and wrapper/ describe a rendering API, not a framework. Choosing Magnum means accepting more of the stack in exchange for less assembly work.

NVRHI is the closest in spirit, a thin abstraction over D3D12 and Vulkan, but it is narrower. LLGL's support table spans OpenGL, D3D11, D3D12, Vulkan and Metal across desktop, mobile, UWP and Wasm, and NVRHI's coverage as reflected in these searches centres on the modern low-level APIs. If you need OpenGL or a WebAssembly target, that breadth is the reason to pick LLGL; if you only target D3D12 and Vulkan, the extra backends are surface area you will not exercise.

## Maintenance, licensing and what upgrading costs

The repository is not archived, and the last push to the default branch was on 2026-09-16. That is recent enough that the project is being touched, but it should be read alongside the release history rather than instead of it: the newest tag is Release-v0.04b from 2025-07-08, and the documentation describes 0.05 Beta. A reader tracking the project should decide whether to follow the master branch or the tagged releases, and should not assume the two describe the same API.

The upgrade cost follows from the version number. While the library is in beta, the ChangeLog at docu/ChangeLog/README.md is the document that tells you what moved between versions. The README links it next to the version string, which is the intended workflow: read the ChangeLog before moving a dependency forward. There is no stated API stability guarantee in the README, and no documented migration guide beyond the ChangeLog itself.

On licensing, LLGL is BSD-3-Clause, and the licence text is at LICENSE.txt in the repository root. A permissive licence of that shape generally imposes attribution and notice-retention obligations rather than source-disclosure ones, which matters if you are linking LLGL into a closed-source engine. This is a description of the licence identifier, not legal advice; read LICENSE.txt and get your own counsel before shipping.

The dependency footprint is worth checking too. vcpkg installs LLGL as a port, and the GNU/Linux build requires X11 and Xrandr development libraries. Those are system-level dependencies that will appear in your build documentation whether or not you mention LLGL in your own README.

## Conclusion

Adopt LLGL if you maintain a renderer or a graphics tool and need one C++ code path across D3D11, D3D12, Vulkan, OpenGL and Metal, including UWP and Wasm targets. Do not adopt it if you want a scene graph, an asset pipeline or a stable released API, because the newest tagged release is Release-v0.04b from 2025-07-08 while the documentation already describes version 0.05 Beta. Before committing, build one example from examples/Cpp on your primary platform and confirm the backend you need is available there, since the support table leaves D3D12 and D3D11 out on Linux and macOS and Metal out on Windows, UWP and Android.

## FAQ

### What is LLGL and which graphics APIs does it support?

LLGL is a low level graphics library that acts as a thin abstraction layer over modern and legacy rendering APIs. The README lists OpenGL, Direct3D 11, Direct3D 12, Vulkan and Metal across Windows, UWP, GNU/Linux, macOS, iOS, Android and Wasm.

### How do I install LLGL?

The README gives a vcpkg route: clone the vcpkg repository, run bootstrap-vcpkg.sh, then vcpkg integrate install and vcpkg install llgl. Alternatively, build scripts are provided for CMake and the build system is documented in the docu/ directory.

### Which platforms can LLGL target?

The support table covers Windows, UWP, GNU/Linux, macOS, iOS, Android and Wasm. Backend availability differs by platform: D3D12 and D3D11 are listed for Windows and UWP only, Metal is marked N/A on Windows, UWP and Android, and Wasm is OpenGL only.

### Is LLGL production ready?

The most recent releases are Release-v0.04b from 2025-07-08, Release-v0.03b from 2023-09-15 and Release-v0.02b from 2018-08-25, all betas, while the README documents version 0.05 Beta. The README does not state an API stability guarantee.

### What language bindings does LLGL provide besides C++?

The README states the library is written mostly in C++11 with the addition of a C99, C# 6.0 and Go wrapper. The examples/ directory has separate C99, CSharp, Cpp and Go trees.

## Sources

- [Issues](https://github.com/LukasBanana/LLGL/issues)
- [License: BSD-3-Clause](https://github.com/LukasBanana/LLGL/blob/master/LICENSE)
- [LukasBanana/LLGL on GitHub](https://github.com/LukasBanana/LLGL)
- [README](https://github.com/LukasBanana/LLGL/blob/master/README.md)
- [Releases](https://github.com/LukasBanana/LLGL/releases)

---

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