intel/compute-runtime: Level Zero and OpenCL Driver for Intel GPUs

What intel/compute-runtime provides

intel/compute-runtime is Intel's open source driver for compute APIs on Intel graphics hardware. It supports both oneAPI Level Zero and OpenCL, so the same driver can serve applications built against either interface. The repository describes its audience as users and developers working with Intel HD Graphics and Xe architectures, including integrated and discrete platforms listed in its support table.

The project is not a general-purpose GPU compute framework. It does not provide kernels, a programming model, or an application runtime in place of Level Zero or OpenCL. Instead, it supplies the hardware-facing runtime that lets compatible applications communicate with supported Intel GPUs. Applications using Level Zero should link with the Level Zero loader, while OpenCL applications should link with the ICD loader library. Direct linking to the runtime library is not supported.

That separation matters for adoption. A system may already have an application and a loader but still lack the Intel compute driver. Conversely, installing compute-runtime does not remove the need for the relevant loader or for an application written for the API it uses.

Platform support and legacy boundaries

The README lists DG1, Alchemist, Battlemage, Tiger Lake, Rocket Lake, Alder Lake, Raptor Lake, Meteor Lake, Arrow Lake, Lunar Lake, Panther Lake, Wildcat Lake, Crescent Island, and Nova Lake. For the listed current platforms, the table reports OpenCL 3.0 and Level Zero 1.18. WSL support is marked as available for the first twelve entries, while Crescent Island and Nova Lake are marked N/A.

Older Gen8, Gen9, and Gen11 devices are handled separately. The README points to documentation/LEGACY_PLATFORMS.md and says that legacy support is delivered through packages with the legacy1 suffix. The legacy table includes OpenCL support for the listed Gen8, Gen9, and Gen11 processors, but Level Zero support varies by device. Gen8 has no Level Zero entry, Gen9 entries report Level Zero 1.5, and the listed Gen11 Core processor reports Level Zero 1.5.

This platform matrix is a hard boundary for evaluation. A system may use a familiar Intel processor name while having a graphics generation, API version, or WSL status that is not covered by the table. The project also states that contributions must not regress support for currently supported hardware.

How the Level Zero and OpenCL layers connect

The repository layout shows separate `level_zero/` and `opencl/` directories, along with shared code and build configuration in `shared/`, `cmake/`, and `platforms.cmake`. The README identifies Level Zero and OpenCL as the supported compute APIs, while the project name NEO is shorthand for the compute runtime and no longer implies one particular API.

For applications, the documented connection is deliberately indirect. A Level Zero application links with the Level Zero loader, not directly with compute-runtime. An OpenCL application links with the ICD loader library. The runtime repository provides the Intel driver layer beneath those API-facing components. This arrangement keeps application linkage tied to the standard loader interfaces rather than to the runtime library itself.

The README does not document a simple application launch command, demo program, or environment variable for NEO. It does identify two important dependencies for the runtime: GmmLib and Intel Graphics Compiler. Performance counter support additionally requires Intel Metrics Discovery and Intel Metrics Library for MDAPI. Those dependency names indicate that the full repository build and optional telemetry support are separate concerns from installing the packaged driver.

Ubuntu installation and first integration check

On Ubuntu 22.04, the README gives this system-package installation command:

apt-get install intel-opencl-icd

This installs the distribution's `intel-opencl-icd` package rather than downloading a binary directly from GitHub. After installation, the user must have permission to access the relevant `/dev/dri/renderD*` device files. The README does not provide a device-permission command, so permission changes must be handled according to the host system's device-management policy.

The first application-level check is therefore integration-oriented. Confirm that the target graphics device is present, confirm that the current user can access its `/dev/dri/renderD*` file, and use an application linked through the documented loader. The README does not document a command for enumerating devices or running a NEO sample, so it would be incorrect to invent one as the project's official first-use procedure.

Intel also publishes `.deb` packages and installation instructions on its GitHub release page. Those artifacts are useful when the distribution package is not suitable, but the package origin should be selected deliberately because releases may also propagate to secondary channels or be repackaged.

Release process and upgrade boundaries

The README states that the release cadence changed from weekly to monthly in late 2022. At the beginning of each calendar month, the project identifies a well-tested driver version from the previous month as a release candidate. Maintainers create a release branch named with the `releases/yy.ww` convention, apply selected fixes, and publish a monthly release from that branch. Later fixes may be cherry-picked during the month, and a hotfix release may be published.

The documented build tag format is `yy.ww.bbbbb.hh`, combining the year and release week, an incremental build number from `master`, and an incremental commit number from the release branch. The repository records recent releases including `26.35.39758.10` on 2026-09-17, `26.31.39395.13` on 2026-08-21, and `26.27.39122.11` on 2026-07-21.

The last push was on 2026-10-16, and the repository is not archived. That indicates current repository activity without by itself proving that every platform has identical quality. The README says platform quality is provided in Release Notes, so upgrades should be checked against those notes and the supported-hardware list rather than selected from version numbers alone.

License, dependencies, and operational trade-offs

The project is distributed under the MIT License, with the license text available at the repository's LICENSE.md file and the license URL identified in the README. That is a permissive project license, but application distribution still requires the reader to account for the licenses of the loader, compiler, metrics components, Linux distribution packages, and any separate dependencies.

The runtime's dependency footprint is a practical adoption constraint. GmmLib and Intel Graphics Compiler are listed as dependencies. Performance counters require two additional Intel components, so a deployment that does not need counters may not need to build or deploy that optional path. The README also warns that debug parameters, environmental variables, and internal data structures may change or be removed at any time. They should not be treated as a stable application configuration interface.

The MIT license and monthly release process do not remove hardware-compatibility work. The project requires continued support across currently supported platforms and communicates deliberate hardware-support changes in release notes. For distribution maintainers, packaging and device access are therefore as important as source availability.

When this driver is the wrong choice

intel/compute-runtime is the wrong choice when the target graphics device is absent from the support tables or when the application directly links to the runtime library. It also does not satisfy an application that requires an API other than Level Zero or OpenCL. The repository is Linux-focused in its documented installation path, and it provides no general instructions for Windows or macOS in the README.

A second limitation is that the runtime is only one part of a working compute stack. The application needs the appropriate loader, the installed driver must match the platform, and the current user must be allowed to access `/dev/dri/renderD*`. A package installation alone does not establish that a device is usable by a particular service account or container.

The project also does not document a stable configuration surface for debug parameters or environment variables. Integrations that depend on those internal details should treat them as version-sensitive rather than as a supported portability layer.

Alternatives and adoption boundaries

The relevant alternative is the operating system's packaged Intel graphics compute driver or a separately maintained distribution package, rather than another application compute framework. The README says NEO is available through Linux distribution package managers and also provides `.deb` packages on GitHub. A distribution package may be easier to receive security and hardware updates through the distribution's normal process, while a GitHub package can provide the release artifacts Intel publishes directly.

The difference is packaging and release channel, not an advertised change to the API implementation. Both choices target the same Level Zero and OpenCL driver role. The README specifically notes that a secondary channel must not release a version that was not first released on GitHub, but it also says packages may be repackaged or rebuilt for convenience. Administrators should therefore compare the package version and source documentation with the release notes.

For a new user, the first verification is concrete: identify the graphics generation, check the platform table, select a package origin, install the driver, verify `/dev/dri/renderD*` access, and link the application through its documented loader.

Editorial conclusion

Adopt intel/compute-runtime when a Linux application needs Level Zero or OpenCL support for a listed Intel graphics platform, and you can maintain the driver through a distribution package or Intel's releases. Do not adopt it for unsupported Intel hardware, direct application linking, or an undocumented installation workflow. Check the hardware table, package origin, device permissions, and the application's required loader before installation.

Frequently asked questions

Official sources

1. intel/compute-runtime on GitHub
2. Issues
3. License: MIT
4. README
5. Releases