ILGPU for .NET GPU programming with CPU debugging

Why ILGPU targets .NET GPU developers

ILGPU solves the problem of writing parallel GPU code while staying within a .NET-based language ecosystem. Its README describes it as a JIT compiler for high-performance GPU programs written in .NET languages, with the implementation written entirely in C# and no native dependencies. That positioning makes it relevant to developers who already use C# and do not want a separate native toolchain for every GPU kernel. It also gives teams a way to express kernels as ordinary C# functions in the scope of kernels, without requiring an annotation for each function. The repository description also names GPU programming, kernels, parallel execution, CUDA, PTX, OpenCL, AMD, Intel and NVIDIA as project topics, while the README explicitly points to samples covering atomics, views, grouped kernels, matrix multiplication, memory-buffer strides and algorithms.

The library is not a general-purpose GPU runtime replacement. It is centered on kernels, accelerators and GPU-oriented algorithms. The README says that functions in kernel scope can use value types, and that hardware features including shared memory and atomics can be executed and debugged on the CPU through the integrated multithreaded CPU accelerator. That CPU path is particularly useful while developing a kernel, because the same kernel concept can be exercised without immediately requiring a CUDA-capable device. The README does not state that every GPU feature has identical semantics or performance on every accelerator.

The ILGPU compilation and execution model

Based on the repository layout and README, ILGPU combines compiler components under `Src/` with algorithms, documentation and sample projects. The central model is JIT compilation: .NET kernel methods are compiled for an accelerator rather than requiring the application to ship a separately authored native kernel implementation. The README describes accelerator types and hardware features rather than exposing a command-line compiler workflow, so the exact intermediate stages are not documented there. It does identify Parallel Thread Execution ISA 7.0, PTX and OpenCL among the references, and the repository topics include CUDA and OpenCL.

The CPU accelerator is an execution target in its own right. According to the README, it is multithreaded and can execute kernels using features such as shared memory and atomics. This creates a useful separation between writing a kernel and committing to a particular GPU environment. It does not mean that CPU execution is a performance substitute for a GPU. No benchmark data, execution result or performance comparison is provided in the project overview.

For reusable computation, `ILGPU.Algorithms` supplies auxiliary functions and higher-level algorithms, including sorting and prefix sum. The README states that these algorithms run on all supported accelerator types. That makes the library useful for kernels that need common reductions or transforms rather than only a custom loop. The repository also contains dedicated samples such as `AlgorithmsReduce`, `AlgorithmsScan`, `AlgorithmsRadixSort`, `AlgorithmsTransform` and `AlgorithmsSequence`, which indicate the intended starting points for studying those APIs.

Installing ILGPU and choosing a build configuration

The README does not provide a one-line installation command, package version, or a complete first-kernel code example. It directs users to the NuGet package page and to the Visual Studio solution, and states that ILGPU requires Visual Studio 2022 or higher and/or a .NET 6.0 SDK toolchain. Build the libraries from the provided Visual Studio solution in the desired `Debug` or `Release` configuration. The repository's `Samples/ILGPU.Samples.slnx` and the `Samples/` directory provide the concrete sample workspace.

For preview or daily builds, the README documents a Feedz package source. Add this configuration to the project's `NuGet.config`:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="ilgpu" value="https://f.feedz.io/ilgpu/preview/nuget/index.json" />
  </packageSources>
</configuration>

This is for preview packages, not a replacement for the release package listed on NuGet. The README also states that official releases use the built-in `NuGet.org Symbol Server`, while preview symbols come from `https://f.feedz.io/ilgpu/preview/symbols`. Visual Studio 2022 must have Source Link support enabled for the documented source-linked debugging experience. The exact sample invocation and accelerator-selection API are not included, so those details cannot be safely supplied.

A practical first kernel workflow

The first real use should begin with the `Samples/` solution rather than with an external application. The repository includes `Samples/Empty`, `Samples/AlgorithmsInitialize`, `Samples/MatrixMultiply`, `Samples/DeviceInfo`, `Samples/ExplicitlyGroupedKernels`, `Samples/ImplicitlyGroupedKernels` and `Samples/GenericKernel`. `Samples/Empty` is the most conservative place to establish the build and execution path. `DeviceInfo` can be used to inspect the accelerator selected by the sample, while the matrix multiplication and grouped-kernel samples show more application-specific kernel structures.

The documented workflow is: install Visual Studio 2022 or higher and/or the .NET 6.0 SDK toolchain, open the provided solution, build in `Debug` or `Release`, and run the relevant sample. The README does not document a CLI command, sample name, accelerator-selection flag, or expected console output, so those details cannot be safely supplied. For a first debugging pass, use the CPU accelerator capability described in the README. For CUDA test cases, the README specifically says `ILGPU.Tests.Cuda` can be unloaded when no CUDA-capable device is available.

The test documentation contains a separate operational caveat: the XUnit test runner may stop when all tests run in parallel. The README attributes this to a known XUnit or Visual Studio problem and says the remaining tests can be run again. This is a test-runner interruption, not a stated ILGPU kernel failure.

CPU debugging, accelerator limits, and feature verification

The CPU accelerator is ILGPU's clearest practical advantage for development. The README says that kernels, including shared memory and atomics, can be executed and debugged on the integrated multithreaded CPU accelerator. That can reduce the feedback loop while a kernel is being written. The repository samples reinforce this focus through CPU-oriented and algorithm-oriented projects, including `AlgorithmsInitialize` and `AlgorithmsSequence`.

The limitation is that CPU execution does not confirm compatibility with a physical accelerator. The README identifies hardware-specific capabilities and mentions CUDA test cases, but it does not provide a complete support matrix, minimum device requirements, fallback policy, or feature-by-feature compatibility table. It also does not claim that CPU debugging reproduces GPU timing, memory behavior, occupancy, or failure conditions. A kernel that works on the CPU may still require verification for the target accelerator's shared memory and atomic support.

This makes ILGPU a poor fit for a team that wants an undocumented native plug-in model, assumes all accelerator features behave identically, or wants a CPU path to serve as proof of GPU performance. The right use is to treat the CPU accelerator as a debugging and algorithm-development target, then check the actual accelerator documentation and device requirements before deployment.

ILGPU.Algorithms and the alternative of prewritten kernels

ILGPU.Algorithms is the project's standard-library counterpart to the compiler. The README names auxiliary functions and higher-level algorithms such as sorting and prefix sum, and states that they can run on all supported accelerator types. This approach is different from writing a complete kernel pipeline in a vendor-specific ecosystem where each operation is tied directly to a CUDA, OpenCL or native library API. ILGPU keeps the algorithm layer in the .NET project and lets the same accelerator abstraction select an execution target.

The alternative is to use a prewritten GPU library or vendor SDK. Its approach is to consume existing device-specific implementations rather than compile .NET kernel methods through ILGPU. That can reduce the amount of ILGPU-specific code when the required algorithm is already available, but the README does not compare ILGPU's performance, API coverage, licensing, or migration cost against any named alternative. The practical difference documented here is architectural: ILGPU compiles .NET kernel functions and provides an algorithm package, while a prewritten library accepts a library API and leaves kernel generation to its own implementation. Teams should compare the actual operation, accelerator support and device requirements rather than infer compatibility from the JIT description.

Licensing, releases, and maintenance cost

The repository identifies the license as the University of Illinois/NCSA Open Source License. The full terms are in `LICENSE.txt`, while `LICENSE-3RD-PARTY.txt` contains dependency copyright and license information. The README lists required dependencies including `System.Collections.Immutable`, `System.Memory`, `System.Reflection.Metadata` and `System.Runtime.CompilerServices.Unsafe`. A prospective adopter should review both license files for its intended use. This is a licensing review, not legal advice, and the README does not state redistribution conditions or obligations beyond identifying the license and the third-party notices.

The repository is not archived. Its last push was on 2026-10-16, so maintenance status should be judged from that date rather than from a claim about ongoing development. The listed releases are `v1.5.3` from 2025-07-12, `v1.5.2` from 2025-03-30, and `v1.5.1` from 2023-09-13. Upgrade planning therefore needs attention to release gaps and the custom preview feed, especially when a project depends on generated kernels or accelerator behavior. The README's requirement for Visual Studio 2022 or higher and/or a.NET 6.0 SDK toolchain is also part of the build cost.

For official debugging symbols, enable `NuGet.org Symbol Server`. For preview builds, use the documented preview symbol feed. Source Link support should be enabled in Visual Studio 2022 options. These are development and maintenance details that matter when selecting a release channel, not just initial installation choices.

Editorial conclusion

Adopt ILGPU when your team needs .NET GPU kernels, CPU debugging, and reusable algorithms in one C# codebase. Do not choose it solely because a kernel runs on the CPU, because that does not establish CUDA, OpenCL, shared-memory, or atomic-operation support on the target device. Verify accelerator availability, device features, build configuration, and the project's University of Illinois/NCSA license obligations first.

Frequently asked questions

Official sources

1. Issues
2. m4rs-mt/ILGPU on GitHub
3. Project website
4. README
5. Releases