# Veldrid: a low-level, portable graphics library for .NET

> Veldrid wraps Direct3D 11, Vulkan, Metal, OpenGL 3 and OpenGL ES 3 behind one .NET API. The README lists the backends and the NuGet package, but the maintainer stopped posting public updates in February 2023, so adoption is a bet on the existing code rather than on a roadmap.

**veldrid/veldrid** — A low-level, portable graphics library for .NET.

- Repository: https://github.com/veldrid/veldrid
- Website: https://veldrid.dev/
- Stars: 2,700 · Forks: 306
- Language: C#
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/veldrid-veldrid

## The portability problem Veldrid is built around

A .NET application that wants GPU rendering normally has two choices. It can bind directly to one native API, which ties the build to one operating system and one driver stack, or it can sit on a higher-level framework that hides the GPU behind scene graphs and asset pipelines. Veldrid takes the middle position. The README calls it a cross-platform, graphics API-agnostic rendering and compute library for .NET, and it lists five backends: Direct3D 11, Vulkan, Metal, OpenGL 3 and OpenGL ES 3. That list is the product. If your code is written against Veldrid's abstractions, the same source can reach Windows through Direct3D 11 or Vulkan, macOS through Metal, and Linux through Vulkan or OpenGL 3.

The audience is narrow and technical. This is not a library for someone who wants a cube on screen in twenty lines. Veldrid is low-level: buffers, textures, pipelines, command lists and a swapchain are the vocabulary, and the README points readers at the documentation site rather than teaching those concepts itself. The people who benefit are engine authors, tool developers and researchers who already know what a render pass is and who want to stop writing three copies of the same renderer. Compute is in scope too, not just drawing, which matters for simulation and image work where the output never reaches a window.

## How the backend abstraction is layered

The repository layout shows the shape of the split. Everything lives under src/, with the public package at the top and the platform-specific implementations underneath it, plus a NeoDemo program that the README describes as a quick demonstration of the rendering capabilities of the library. The README does not spell out the internal call flow, so treat any diagram of it as reconstruction rather than documentation.

What the README does establish is the contract you code against. Resources such as buffers and textures are created through the library, and the same creation call is expected to work whichever backend is active. The backend then translates that request into the native API: a Direct3D 11 device and context, a Vulkan device and queue, a Metal device and command queue, or an OpenGL context. Resource lifetime is explicit, which is why the API feels heavier than a scene graph but gives you control over when GPU memory is allocated and released.

The practical consequence is that portability is a property of the abstraction, not a guarantee about behaviour. Two backends can differ in feature support, in how they report errors, and in what the driver does with a malformed pipeline description. Veldrid narrows the surface you have to write, but it does not remove the need to test on each backend you intend to ship.

## Installing Veldrid and getting NeoDemo on screen

Veldrid ships as a NuGet package, so installation is a package reference in your project file. The README gives the package name Veldrid and links to its NuGet page; it also notes that pre-release versions are published to a MyGet feed at https://www.myget.org/feed/mellinoe/package/nuget/Veldrid. Add the stable package first.

```bash
dotnet add package Veldrid
```

That command resolves the latest stable release. The most recent one listed for the project is v4.9.0, dated 2023-02-03, so expect that generation of the API rather than anything newer.

To see the library actually render, build the repository itself. The README states that Veldrid uses the standard .NET Core tooling and that a normal build is dotnet build, and it names NeoDemo as the program to run for a quick demonstration.

```bash
git clone https://github.com/veldrid/veldrid.git
cd veldrid
dotnet build
```

After the build completes, run the NeoDemo project from the solution. What you should see is a window driven by Veldrid's rendering path on whichever backend the machine supports. If the window fails to appear, that is the first signal that the backend selection or the native driver stack on your machine needs attention, and it is worth resolving before you write any of your own rendering code.

The README does not document a backend-selection flag, an environment variable or a configuration key for forcing a particular API. If you need to pin one backend for testing, look at how NeoDemo itself is wired up in src/ rather than expecting a documented switch.

## The maintenance question the README answers directly

Most project pages leave maintenance status to be inferred. This one does not. The README carries a notice dated February 2023 stating that the author is no longer able to publicly share updates to Veldrid and related libraries, and directing active users and past contributors to a Discord server for information about the status of the project. That sentence should shape how you evaluate everything else on the page.

The repository is not archived, and the last push was on 2026-03-17. So the code is not frozen and the project has not been formally retired, but the README's own statement means you should not read commit activity as a product roadmap. The release list reinforces the point: v4.9.0 in February 2023, and before that v4.3.3 in 2018 and v4.2.0 in 2018. A user adopting today is adopting a stable, feature-complete library with no published plan for what comes next.

That is a defensible position for a graphics abstraction layer. Graphics APIs change slowly, and a library that already covers Direct3D 11, Vulkan, Metal, OpenGL 3 and OpenGL ES 3 covers the backends most .NET applications need. It is a bad position if your project depends on a vendor answering questions, shipping fixes on a schedule, or adding a backend you need later.

## Where Veldrid is the wrong tool

The first limitation is scope by design. Veldrid is a graphics and compute library. It does not create windows, handle input, load models, or manage a scene. The README says nothing about windowing, and the documentation site is where the project sends readers for anything beyond the description. If you want an application framework with a window, a camera and an input loop, you are assembling that yourself or pairing Veldrid with another library.

The second is the feature-parity assumption. Five backends is a claim about coverage, not about identical behaviour. A pipeline that works on Vulkan may hit a different limit on OpenGL ES 3, which is a constrained API by comparison. Veldrid gives you one interface, but you still own the testing matrix for every backend you ship.

The third is the support model. The README's own notice about public updates means there is no expectation of upstream fixes for a driver quirk you hit next year. For a hobby renderer or an internal tool, that is acceptable. For a commercial product with a support obligation, it is a risk you have to price in before writing the first pipeline.

## Veldrid against Silk.NET

The natural comparison in .NET graphics is Silk.NET, which people search for alongside Veldrid. The two sit at different levels and that difference decides the choice.

Silk.NET binds the native APIs. You get Vulkan, OpenGL, Direct3D and others as generated C# bindings that follow the C headers closely, so what you learn transfers to the native documentation and to examples written in other languages. The cost is that portability is your problem: moving from Vulkan to Metal means writing a second renderer, because the binding exposes the API rather than an abstraction over it. You also take on the raw handle management that comes with that.

Veldrid inverts both. You learn Veldrid's resource and pipeline model, and the library translates it to the backend. Portability is the feature you are buying, and the price is an extra layer between your code and the driver plus a smaller ecosystem of examples. If you are targeting one platform and want direct control, the binding approach is more direct. If you need the same renderer on Windows, macOS and Linux without maintaining three code paths, Veldrid's abstraction is the reason to pick it.

## Licence and the cost of staying on this version

Veldrid is MIT licensed. That is permissive: it allows use in closed-source products, modification, and redistribution, provided the copyright notice and permission notice are preserved. The LICENSE file sits at the top level of the repository. This is a description of the licence text, not legal advice, and if your organisation has specific obligations around attribution in shipped binaries, that is a question for your own counsel.

The upgrade cost is unusual here, because there is little to upgrade to. The newest release listed is v4.9.0 from 2023-02-03, and the README's February 2023 notice explains why. Practically, that means the version you adopt is close to the version you will keep. There is no migration treadmill, which is a real benefit for a long-lived internal tool, and no upstream fixes, which is the matching cost. If you build on Veldrid, budget for the possibility that you maintain your own fork for the backends and bug fixes you care about. The repository is public and MIT licensed, so that option is open, but it is work you are taking on rather than work you are delegating.

## Conclusion

Use Veldrid if you need one .NET rendering or compute API across Direct3D 11, Vulkan, Metal, OpenGL 3 and OpenGL ES 3, and you accept that the README says public updates stopped in February 2023. Do not pick it if you need a maintained upstream, a support contract, or a windowing and input layer, since the README describes a graphics library and nothing else. Before committing, install the Veldrid package from NuGet, build the repository with dotnet build, and run NeoDemo to confirm your target machine reaches a working backend.

## FAQ

### What is Veldrid?

Veldrid is a cross-platform, graphics API-agnostic rendering and compute library for .NET, described in its README as a unified interface to a system's GPU. It supports Direct3D 11, Vulkan, Metal, OpenGL 3 and OpenGL ES 3.

### How do I install Veldrid?

It is distributed as the NuGet package Veldrid, so you add it with dotnet add package Veldrid. Pre-release versions are also published to a MyGet feed at https://www.myget.org/feed/mellinoe/package/nuget/Veldrid.

### Which graphics APIs does Veldrid support?

The README lists five backends: Direct3D 11, Vulkan, Metal, OpenGL 3 and OpenGL ES 3. Which one is used depends on the platform and what the machine supports.

### Is Veldrid still maintained?

The README states that as of February 2023 the author is no longer able to publicly share updates to Veldrid and related libraries, and points users to a Discord server for the status of the project. The repository is not archived and the last push was on 2026-03-17, but the README itself sets no expectation of future releases.

### How do I run the Veldrid demo?

The README says to build the repository with the standard .NET Core tooling using dotnet build, then run the NeoDemo program, which it describes as a quick demonstration of the library's rendering capabilities.

## Sources

- [License: MIT](https://github.com/veldrid/veldrid/blob/master/LICENSE)
- [Project website](https://veldrid.dev/)
- [README](https://github.com/veldrid/veldrid/blob/master/README.md)
- [Releases](https://github.com/veldrid/veldrid/releases)
- [veldrid/veldrid on GitHub](https://github.com/veldrid/veldrid)

---

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