Phoronix first reported the Nova Lake default and the introduction of Intel Portable ISA, or PISA, in the September 17 release. Intel’s own Compute Runtime release record confirms both the Nova Lake “early support” designation and the LEO enablement for the NVL platform. It also confirms the more consequential operational detail absent from the broader announcement: a version-skewed OpenCL and Level Zero installation is a known failure condition on Nova Lake.
For developers targeting Intel GPUs, the release is less about a finished Nova Lake compute platform than about Intel changing the plumbing beneath OpenCL and beginning to expose a portable compilation target for future Xe hardware.
LEO moves OpenCL onto Level Zero
Intel’s traditional OpenCL implementation communicates more directly with the graphics hardware through its Compute Runtime stack. LEO takes a different route: it implements OpenCL through Intel’s Level Zero APIs, which are the lower-level oneAPI interface intended for direct GPU control.
That design has been under active development throughout 2026. Intel introduced LEO experimentally in Compute Runtime 26.22.38646.4 in June, retaining the older path as the normal route for Intel’s established integrated and discrete GPUs. The September 17 build is the first release where Intel says LEO is enabled by default for Nova Lake, identified internally as NVL.
The distinction is practical. A translation layer can consolidate development around Level Zero and allow Intel to add OpenCL functionality without maintaining two completely separate routes to the GPU. The trade-off is maturity: Intel continues to classify LEO as experimental for existing platforms, and Nova Lake itself is still “early support,” a label Intel defines as carrying no quality expectations.
That status matters more than the switch being enabled by default. It means the change is an enablement milestone for developers and Linux distribution maintainers, not a reason for administrators to treat Nova Lake OpenCL deployments as production-ready.
The mixed-package failure Intel documents
Intel’s release notes contain one clear warning for anyone installing or updating components manually: OpenCL on Nova Lake will not work with a Level Zero runtime package older than Compute Runtime 26.35.39758.10. Intel lists three workarounds—upgrade the Level Zero package to the matching release, remove the older package, or disable LEO with the EnableLEO=0 environment setting.
This is a familiar problem in GPU compute stacks, where the OpenCL ICD, the Level Zero driver, compiler packages, and distribution-provided dependencies may arrive through different repositories or update schedules. The important change is that LEO makes the dependency explicit. An OpenCL package that looked current enough on its own can now fail because the Level Zero half of the stack was held back.
For Linux desktop and workstation administrators, the safest approach is to upgrade the Compute Runtime pieces as a matched set rather than selectively replacing intel-opencl-icd. Intel’s published Ubuntu 26.04 installation procedure pairs the new OpenCL ICD and Level Zero GPU packages with Intel Graphics Compiler 2.41.5, and includes checksums for the released Debian packages.
The fallback switch is useful for diagnosis, but it should not be mistaken for a permanent fix. Disabling LEO restores the older behavior; it does not resolve the underlying mismatch. If an application starts working only after EnableLEO=0, the installation has identified exactly what should be corrected before LEO becomes more broadly enabled.
Windows support stops short of Nova Lake WSL
Phoronix describes Compute Runtime 26.35.39758.10 as an update for Windows and Linux, and Intel’s release matrix states that WSL was tested using Windows graphics driver 101.8991. But the table assigns “N/A” to WSL for both Nova Lake and Crescent Island, even as it lists WSL support for platforms from DG1 through Wildcat Lake.
That is the key boundary Windows users should observe. The release provides no basis to claim that Nova Lake LEO is ready inside WSL, and Intel’s published installation assets for this release are Ubuntu .deb packages. The new default is explicitly a Linux Nova Lake S change.
Developers working in WSL on supported Intel platforms may still benefit from the updated Level Zero 1.17 runtime and associated compiler changes, assuming their Windows host graphics driver meets Intel’s tested version. But Nova Lake development should remain on a native Linux test path until Intel adds an affirmative WSL designation rather than leaving the field unavailable.
This is not a cosmetic omission. GPU compute under WSL relies on both the Windows host driver and the Linux guest runtime agreeing on the relevant interfaces. Intel’s own matrix shows it has not yet made that compatibility commitment for Nova Lake.
PISA is Intel’s bid for a portable GPU binary target
The same update adds initial Compute Runtime support for PISA, Intel’s Portable ISA. Intel’s PISA documentation describes it as a stable, portable instruction set for compilers targeting Intel GPUs, designed to retain performance close to native machine code while supporting more advanced programming models such as hand-written libraries and inline assembly.
In broad terms, PISA would sit between a developer’s high-level source code and the final machine instructions for a particular Intel GPU. A compiler could produce PISA, ship it in an application or offload image, and allow Intel’s runtime to finalize it later for the GPU actually present. That arrangement is intended to reduce the need to distribute a separate precompiled binary for every future Xe variant.
The closest industry comparison is NVIDIA’s PTX, although Intel has not presented PISA as a direct one-for-one equivalent or published end-user performance results for this first implementation. PISA arrives as infrastructure, not a feature an ordinary OpenCL user can enable to gain an immediate speedup.
Intel engineers have also been pursuing an LLVM PISA back end. In an LLVM project discussion about upstreaming that work, Intel’s explanation was that the SYCL toolchain would eventually emit PISA directly, with the Compute Runtime finalizing it to Xe assembly at runtime. That gives the runtime support in 26.35.39758.10 a larger implication: Intel is laying groundwork for a compiler-to-runtime chain, rather than merely adding another internal file format.
What developers should and should not do now
The release upgrades the stack’s advertised Level Zero support from version 1.15 to 1.17 across its listed current platforms. It also adds OpenCL work including the cl_khr_spirv_queries extension and command-buffer infrastructure, plus runtime-side features such as external semaphores, system-management information logs, early composite-temperature reporting, and memory vendor-ID retrieval.
Those additions will matter differently depending on workload. OpenCL applications that ship SPIR-V, use command recording, or depend on fine-grained synchronization are the most likely to encounter the practical effect before ordinary desktop software does. Enterprise monitoring tools may eventually benefit from the newer Sysman telemetry, but “initial” composite temperature support should be treated as a capability under construction rather than a replacement for established hardware monitoring.
For most Windows PC owners, there is nothing to install solely because PISA appeared in the release notes. The immediate action belongs to developers, CI maintainers, and Linux or WSL users who package Intel’s GPU compute components:
- Keep the OpenCL ICD and Intel Level Zero GPU runtime on the same 26.35.39758.10 release when testing Nova Lake LEO.
- Do not interpret Nova Lake’s “early support” status as an assurance of application compatibility, stability, or performance.
- Do not assume Nova Lake GPU compute is supported in WSL merely because Intel tested WSL with Windows driver 101.8991 for other platforms.
- Treat PISA as an early compiler and runtime development target until Intel publishes toolchain support, stability guarantees, and performance evidence.
Intel has made a concrete architectural choice for Nova Lake: OpenCL’s newer LEO route is now the default there. But the first release also makes clear that the real test is deployment discipline—matching the driver components correctly on Linux—and that Windows-hosted Nova Lake development through WSL remains outside Intel’s published support matrix.