ComputeSharp: Running C# Compute and Pixel Shaders on DX12
A .NET library to run C# code in parallel on the GPU through DX12, D2D1, and dynamically generated HLSL compute and pixel shaders, with the goal of making GPU computing easy to use for all .NET developers! 🚀
At a glance
- What is it?
- ComputeSharp is a .NET library that compiles C# shader methods into HLSL and dispatches them on the GPU through DX12 and D2D1. It targets Windows-only .NET developers who want GPU compute without writing HLSL by hand.
- Who is it for?
- Adopt ComputeSharp if you ship a Windows .NET application, you already know C#, and the work you want to offload maps cleanly onto compute or pixel shaders. Do not adopt it for cross-platform GPU compute, for non-Windows servers, or if your team is already fluent in HLSL and CUDA and has no reason to move that code into the .NET build.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem ComputeSharp solves for Windows .NET developers
Writing GPU code normally means leaving your language. You write HLSL, compile it, marshal buffers across a COM boundary, and keep two build systems in sync. ComputeSharp removes that split for one specific audience: developers writing .NET code that runs on Windows and needs the GPU.
The README states the goal directly: to make GPU computing easy to use for all .NET developers. The mechanism is a source generator. You write a C# method marked as a shader, and the library generates the HLSL and the surrounding DirectX plumbing. The README describes the library as running C# code in parallel on the GPU through DX12, D2D1, and dynamically generated HLSL compute and pixel shaders. That word dynamically is the important one: the HLSL is produced at build time from your C#, not hand-written.
Who is this for? The README names two production users. The Microsoft Store uses ComputeSharp.D2D1.Uwp for custom effects and pixel shaders behind graphics elements such as app cards, starting from the January 2023 release. Paint.NET uses ComputeSharp.D2D1 as a core component of its architecture from its 5.0 release, both for built-in effects and for external plugins. The README also notes that ComputeSharp.D2D1 was initially developed specifically to support Paint.NET. That is a narrow but real track record: Windows desktop imaging and UI work, not general scientific computing on Linux clusters.
How the source generator turns C# into HLSL
The architecture has two halves. On one side, the source generator reads your shader methods and emits HLSL plus the C# interop code needed to load it. On the other, a runtime layer talks to DirectX: it enumerates GPU devices, allocates buffers and textures, and moves data between GPU memory and RAM. The README lists exactly those capabilities: access GPU devices, allocate GPU buffers and textures, move data between them and the RAM, write compute shaders entirely in C# and have them run on the GPU.
The repository layout reflects this split. The top level has src/, tests/, samples/, libs/, build/ and docs/. The samples directory is the most informative part for a newcomer: it contains ComputeSharp.Sample, ComputeSharp.ImageProcessing, ComputeSharp.Benchmark, a CLI swap chain sample, UWP and WinUI swap chain samples, D2D1 variants, and an F# sample with a separate shaders project. The presence of ComputeSharp.Sample.FSharp.Shaders as its own project is a hint about how shader compilation is wired into a build: shaders live in a project that the generator processes, and the consuming application references the result.
The README points to a master's thesis in the repository, docs/ComputeSharp.pdf, which it says covers the DirectX interop infrastructure, the source generators including a breakdown of the generated code, how HLSL intrinsics are transpiled, and how Win2D was extended to support custom effects. If you need to understand what the generator emits before trusting it in a shipping product, that document is the place the project itself sends you.
Installing ComputeSharp and writing a first shader
ComputeSharp ships as NuGet packages. The README lists nine of them, and picking the right one matters more than the install command. ComputeSharp is described as the main library with compiled shaders support. ComputeSharp.D2D1 is for D2D1 pixel shaders and ID2D1Effect registration. ComputeSharp.WinUI and ComputeSharp.Uwp provide controls to render DX12 shaders. ComputeSharp.Dxc bundles the DXC compiler and enables shader reflection. ComputeSharp.D3D12MemoryAllocator swaps in D3D12MA as the memory allocator. ComputeSharp.Pix adds PIX debugging support.
The README points to the wiki pages for detailed samples on all features and APIs, and the repository carries a samples/ directory with projects such as ComputeSharp.Sample, ComputeSharp.ImageProcessing and the swap chain samples. That is the honest boundary: the README does not include a runnable hello-world, so the wiki and the samples are where the actual code lives.
One practical note from the repository layout: the solution file is ComputeSharp.slnx, and there is a global.json at the root pinning the SDK. If you clone the repository to read the samples, expect the build to enforce that SDK version rather than whatever you have installed.
Where ComputeSharp is the wrong tool
The platform constraint is the first limitation and it is not a small one. The library is built on DX12 and D2D1. Those are Windows graphics APIs. Nothing in the README claims Linux, macOS, or non-Windows server support, and the package list reinforces this: UWP and WinUI controls, D2D1 effects, PIX debugging. If your workload runs on a Linux container farm or you need the same code path on macOS, this library does not offer one.
The second limitation is the shader model itself. A shader is not general-purpose code. You are writing a method that runs across many GPU threads with restricted control flow, and the generator has to translate it into HLSL. The README mentions an F# sample with a separate shaders project, which suggests shader code is compiled through its own project rather than scattered through your application. That is a build-organization cost you take on before you see any speedup.
The third is debugging. The README lists ComputeSharp.Pix as an extension that enables PIX support to produce debugging information, and ComputeSharp.Dxc as bundling the DXC compiler and enabling shader reflection. Both are separate packages, which means the default experience does not include them. If you expect to step through GPU code the way you step through C#, you will be adding packages and learning a Windows graphics debugger.
Finally, the README does not document rollback, version compatibility matrices, or a support policy. There is no statement about which .NET versions each package targets, beyond the netstandard topic tag on the repository. Verify that yourself against the package metadata before you plan an upgrade.
ComputeSharp compared with ILGPU
ILGPU is the alternative that comes up most often, and the difference is in the backend rather than the language. Both let you write GPU kernels in .NET. ILGPU compiles kernels for multiple backends, which is why it appears in searches alongside ComputeSharp. ComputeSharp is tied to DX12 and D2D1, and that tie is the source of both its strengths and its limits.
The practical consequence: if your application is a Windows desktop app with a UI, ComputeSharp's D2D1 and WinUI packages let a shader participate in the rendering pipeline as a first-class effect, and the README's production examples are exactly that shape. If your application is a headless compute job that might need to run on a Linux machine, ComputeSharp's Windows-only foundation is a wall, not a preference.
A second difference is scope. ComputeSharp covers compute shaders and pixel shaders, plus D2D1 effects and rendering controls. ILGPU is oriented around kernel execution. Neither is a strict superset of the other; they overlap on the compute dispatch path and diverge on everything around it.
Maintenance, licence and upgrade cost
The repository is not archived, and the last push was on 2026-09-18, which is recent. The most recent release listed is v3.2.0 from 2025-04-14, preceded by v3.1.1 on 2025-03-15 and v3.1.0 on 2024-12-24. So the cadence visible in the release list is roughly a minor release every few months, with the repository receiving commits more often than it publishes versions.
The licence is MIT, stated in the repository and in the LICENSE file at the top level. MIT is permissive: it allows commercial use and modification, and it requires that the copyright notice and permission notice be preserved. That is a summary of what the licence type means, not legal advice; read the LICENSE file and your own organisation's policy. There is also a ThirdPartyNotices.txt at the root, which matters because the library wraps DirectX components and the DXC compiler, and those carry their own terms.
Upgrade cost is hard to estimate from the README, because it does not publish a compatibility matrix. What the repository does show is a Directory.Packages.props file, meaning central package version management is in use, and a global.json pinning the SDK. Both are signals that the project takes its own dependency graph seriously. For consumers, the risk sits in the source generator: a change in how C# shader methods are translated into HLSL can change generated code without changing your source. Pin your package version and re-run your shader tests on upgrade.
Editorial conclusion
Adopt ComputeSharp if you ship a Windows .NET application, you already know C#, and the work you want to offload maps cleanly onto compute or pixel shaders. Do not adopt it for cross-platform GPU compute, for non-Windows servers, or if your team is already fluent in HLSL and CUDA and has no reason to move that code into the .NET build. Before committing, verify that your target GPUs are DX12 capable, that the shader method you plan to write compiles under the source generator, and read the wiki pages for the specific package you intend to reference, because ComputeSharp, ComputeSharp.D2D1 and the WinUI and UWP packages have different platform requirements.
Frequently asked questions
What can compute shaders be used for?
The README describes ComputeSharp as running C# code in parallel on the GPU through DX12, D2D1, and dynamically generated HLSL compute and pixel shaders, and says you can use it for things from scientific simulations to animated backgrounds and audio visualizers. It also lists production uses in the Microsoft Store for graphics elements such as app cards, and in Paint.NET for built-in effects and external plugins.
Which is better, compute shaders or CUDA?
The README does not compare ComputeSharp with CUDA, so it offers no basis for that judgement. What it does state is that ComputeSharp targets DX12 and D2D1, which are Windows graphics APIs, and that its goal is to make GPU computing easy to use for all .NET developers.
What does GPU compute do?
In ComputeSharp's terms, it means running C# code in parallel on the GPU rather than on the CPU. The README lists the available APIs as accessing GPU devices, allocating GPU buffers and textures, moving data between them and the RAM, and writing compute shaders entirely in C# to run on the GPU.
What is the purpose of shaders?
The README presents shaders as the unit of work the library generates and dispatches: compute shaders written entirely in C#, and pixel shaders used for rendering effects. It notes that several pixel shaders originally from shadertoy.com were ported from GLSL to C# and run with ComputeSharp in a WinUI 3 sample app.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/sergio0694-computesharp)