Intel adds early Nova Lake support and experimental LEO to Compute Runtime

{{IMAGE:2}}

Intel released Compute Runtime 26.22.38646.4 on June 16, 2026, with early Nova Lake Xe3P support for OpenCL 3.0 and oneAPI Level Zero 1.15. The same release keeps Crescent Island, Intel's coming AI accelerator, in early support.

Intel has worked on Nova Lake support in its open-source GPU compute stack since January. With this release, Intel now lists Nova Lake in its quality and feature matrix instead of leaving the platform hidden behind bring-up code.

That matters for Linux builders because Intel Compute Runtime sits under OpenCL and oneAPI Level Zero workloads on Intel graphics hardware. The stack still supports Tiger Lake integrated graphics and newer platforms, plus DG1 and later discrete GPUs.

Nova Lake support

Intel added several Nova Lake-specific pieces in this release. Nova Lake S now gets OpenCL buffer pool support. Nova Lake P gets kernel compilation handling. Intel also enabled Ultra Low Latency Scheduling, or ULLS, for Nova Lake P and Nova Lake S.

Those changes point to platform bring-up that has moved from basic device recognition into workload plumbing. Kernel compilation, buffer allocation, and scheduling behavior shape whether OpenCL and Level Zero applications run with sane latency and stable throughput.

Intel also added broader performance work across the runtime. Engineers increased pre-allocated heap counts, added resource pre-allocation, enabled thread data cache use, and wired more Xe-device handling paths.

Intel has not published Nova Lake Compute Runtime benchmarks with this release. For a homelab or workstation buyer, that means you should treat the new support flag as a compatibility signal, not a performance guarantee. Run your own OpenCL and Level Zero tests before you plan a Nova Lake system around GPU compute.

A useful smoke-test set would include clinfo, OpenCL sample kernels, oneAPI Level Zero samples, and your target workload. Measure kernel compile time, steady-state throughput, memory transfer rate, and package power under load.

LEO changes Intel's OpenCL path

The larger architectural change comes from LEO, short for Level Zero Executing OpenCL. Intel added LEO as an experimental project inside Compute Runtime.

LEO reimplements the OpenCL API on top of Intel's Level Zero interface. Intel engineers now maintain separate OpenCL and Level Zero paths in the runtime. LEO gives Intel a route toward one lower-level driver path, with OpenCL calls mapped onto Level Zero.

That design could help Intel reduce duplicated code and test more behavior through one stack. It could also expose OpenCL users to performance work that Intel lands first in Level Zero.

LEO still needs caution. Intel calls the project experimental, and the implementation lacks some OpenCL extensions. Developers who ship OpenCL applications should test extension coverage, numerical behavior, queue behavior, and error handling before they compare LEO against Intel's native OpenCL path.

LEO also gives Linux graphics testers a fresh comparison point against Mesa's Rusticl, the Rust-based OpenCL implementation in Mesa. Rusticl targets broad Gallium driver coverage. Intel LEO targets Intel's Level Zero stack. Those goals differ, so benchmark results will depend on the device, kernel style, and driver path.

Compatibility notes

Intel Compute Runtime 26.22.38646.4 advertises OpenCL 3.0 and Level Zero 1.15 support for Nova Lake. The runtime still reaches back to Tiger Lake integrated graphics and DG1 discrete graphics.

The release also adds support for reading maximum GPU temperature, adds ECC API support through sysman for Crescent Island, and supports group engine handles for Xe devices. Those sysman and telemetry pieces matter for servers because operators need temperature, ECC status, and engine visibility before they put accelerators into long-running jobs.

Kernel and compiler alignment still matter. Nova Lake support depends on the Intel Graphics Compiler, available at intel/intel-graphics-compiler, and the Linux Xe kernel driver. Builders should pair the runtime with a recent kernel, matching IGC packages, and firmware from the same distribution channel where possible.

Build recommendations

Do not buy Nova Lake hardware today only for OpenCL or Level Zero throughput unless you can accept early-driver behavior. Intel's support label means developers can start testing. It does not tell you how fast Nova Lake will run your kernels.

For workstation planning, Nova Lake now looks safe enough for bring-up testing, CI coverage, and application validation. Keep a known-good Arc, Core Ultra, or Xe-LP platform nearby if you need baseline comparisons.

For servers, wait for Intel to move Nova Lake from early support to production support before you standardize fleet images. Intel often makes that move near product launch, but release timing depends on hardware readiness, firmware, kernel support, and validation results.

Power testing should come early in your validation plan. Measure idle package power, sustained OpenCL load, burst behavior during kernel compilation, and thermals after 30 minutes or more. Temperature telemetry support helps, but you still need wall power and workload-level counters to size cooling and power budgets.

Intel's release gives Linux GPU compute users two things to test: Nova Lake Xe3P bring-up and LEO's OpenCL-on-Level-Zero path. The first helps future client systems. The second could reshape Intel's OpenCL maintenance model if Intel closes the extension gaps and matches native-driver performance.