Intel's open-source Compute Runtime stack for OpenCL and oneAPI Level Zero on their graphics processors has been bringing up Nova Lake support since January. With today's release of the Intel Compute Runtime 26.22.38646.4, the Nova Lake Xe3P support has matured to the state of it being advertised now as under an "early support" status.

The Intel Compute Runtime 26.22.38646.4 release today adds Nova Lake to their quality/feature matrix in advertising OpenCL 3.0 and Level Zero 1.15 support. The Compute Runtime support continues to extend back to Tiger Lake integrated graphics or DG1 on the discrete graphics side. The upcoming Crescent Island AI accelerator also continues to be advertised as "early support" with this open-source GPU compute stack.

Typically right around product launch time is when Intel moves the quality expectations for a given platform from "early support" to "production" status. But with Nova Lake now marked as "early support" is a likely indicator of good base support now in place for Nova Lake / Xe3P with the Compute Runtime and in turn the Intel Graphics Compiler (IGC) and Xe kernel driver.

For Nova Lake S the OpenCL buffer pool is now enabled, Nova Lake P now has kernels compilation handling, enabling Ultra Low Latency Scheduling (ULLS) for Nova Lake P and Nova Lake S, and other missing Nova Lake bits are now wired up.

There is also other performance work in general like explicitly pre-allocating resources, increasing the amount of pre-allocated heaps, enabling the thread data cache, and more. Other changes include support for reading the max GPU temperature, ECC API support with sysman for Crescent Island, supporting group engine handles for all Xe devices, and different fixes.

There is also one other big change with today's Intel Compute Runtime update and that is introducing LEO: Level Zero Executing OpenCL. Intel LEO is a currently-experimental project within the Compute Runtime that re-implements the entire OpenCL API from scratch atop of their Level Zero interface. Rather than having to maintain two driver stacks with OpenCL and Level Zero, the hope is to eventually just have everything mapped to Level Zero.

If this experimental project pays off, it will be possible to maintain just one (Level Zero) driver stack, reduce the maintenance burden for Intel engineers, increase test coverage thanks to the consolidation, and tap more performance gains from Level Zero.

I'll be trying out Intel LEO soon to see how this OpenCL implementation compares to its existing native OpenCL driver and benchmarks. But, again, it's currently experimental and not all OpenCL extensions are yet in place. It will also be interesting to see how Intel LEO compares to Mesa's generic Rusticl driver.

Today's exciting Compute Runtime update can be downloaded from GitHub.