“Is Intel Arc supported on Linux?” is the wrong question, or at least an incomplete one. It reads as a single yes/no toggle, and the answer that comes back — usually “yes” — hides the thing that actually determines whether your workload runs: which layer of the stack you actually depend on. A team can boot an Arc card on a recent Ubuntu kernel, get crisp desktop rendering and hardware video decode, and conclude the card is “supported” — then discover months later that their SYCL inference path stalls or silently falls back because the compute runtime for their toolchain release is not production-ready. That gap is the whole story. Intel Arc on Linux is not one support surface but three, and they mature at different rates. Confusing them is how a portability play turns into a hardware budget spent on a card whose compute stack is not yet ready for the workload class you bought it for. The three layers behind the word “supported” When someone says Arc “works on Linux,” they are usually describing one of three distinct things stacked on top of each other. Each has its own version cadence, its own maturity curve, and its own failure modes. The kernel graphics driver is the bottom layer. For Arc discrete GPUs this is the i915 driver on older kernels and the newer Xe (xe) kernel driver that Intel has been transitioning to for its Xe-architecture parts. This layer handles mode-setting, display output, and the low-level command submission that makes the card a functioning graphics device. It is the layer that determines whether your desktop lights up and whether hardware video decode works. It matures fastest because it rides the mainline Linux kernel release train, and it is the layer people mean when they casually say “Arc is supported now.” The userspace compute runtime sits above the kernel driver. This is where the Level Zero API and Intel’s OpenCL implementation live — the intel-compute-runtime (NEO) stack. This layer exposes the GPU to compute frameworks. It is versioned independently of the kernel, and its readiness for a specific card can lag the graphics driver by a meaningful margin. A card that displays perfectly can still have a compute runtime that is missing kernels, mis-reporting device capabilities, or performing well below the hardware’s ceiling for a given operation class. The oneAPI / SYCL toolchain is the top layer — the Intel oneAPI DPC++ compiler, the oneAPI base toolkit, and the SYCL runtime that actually compiles and dispatches your workload. This is what you build against when you write portable heterogeneous code. Its support matrix is defined per oneAPI release, and a given release may officially support only a subset of Arc SKUs, or support them with caveats around specific data types or libraries (oneMKL, oneDNN). The divergence point is compute. Display and video ride the kernel driver and reach usable maturity early. Your actual machine-learning inference or simulation workload rides the runtime and the toolchain, and those two upper layers are where “supported” fractures into “supported for what, at which version, at what performance.” Which layer does “supported” actually refer to? This is the question the marketing checkbox never answers, and it is the one that decides your roadmap. The answer depends entirely on what you are trying to run. If you are building a workstation for developers who need a display and occasional GPU-accelerated video work, the kernel graphics driver is your support surface, and Arc reaches usable status quickly on any reasonably current kernel. If you are running a portable compute codebase — OpenCL or SYCL — the runtime and the toolchain are your support surface, and the kernel driver being mature tells you almost nothing about whether your workload runs at competitive performance. We see this confusion most often in procurement conversations, where someone has read that Arc “supports Linux” and built a hardware plan around it without asking which of the three layers the claim referred to. The correct move is to identify your dependency layer first, then check the version matrix for that layer against your target card, rather than trusting the aggregate “supported” claim. This is the same layered-verification discipline that applies whenever you evaluate a non-NVIDIA target as a vendor-neutral GPU compute path — the vendor’s headline support figure and the runtime your code actually calls are rarely the same thing. Layer-by-layer readiness at a glance Layer What it is Determines Version cadence Matures Kernel graphics driver i915 / Xe (xe) kernel modules Display, mode-setting, video decode Mainline kernel releases Earliest Compute runtime Level Zero + OpenCL (intel-compute-runtime / NEO) Whether frameworks see the GPU as a compute device Independent packages Middle oneAPI / SYCL toolchain DPC++ compiler, oneAPI toolkit, oneMKL/oneDNN Whether your portable code compiles, dispatches, and performs Per oneAPI release Latest (Readiness ordering is an observed pattern across the driver-stack transition; the exact version thresholds shift with each kernel and oneAPI release, so treat the “matures” column as relative, not absolute.) The practical consequence: a readiness verdict is never a single fact. It is a tuple — kernel version, Level Zero / OpenCL runtime version, and oneAPI/SYCL release — evaluated against your specific workload class. What kernel and driver versions do I need for Arc compute? For discrete Arc compute under Linux, the useful mental model is that you need three things aligned, not one. First, a kernel new enough to enumerate your specific Arc card as a compute device — this is where the i915-to-Xe driver transition matters, because Intel has been moving Xe-architecture discrete GPUs onto the newer xe kernel driver, and which driver claims your card depends on both the kernel version and the card generation. Second, an intel-compute-runtime (the NEO OpenCL and Level Zero userspace stack) recent enough to expose the full compute capability of that card rather than a degraded subset. Third, a oneAPI release whose support matrix lists your card. The failure mode when these are misaligned is rarely a clean error. More often the device enumerates, a SYCL or OpenCL context is created, and then a specific kernel underperforms or a library call falls back to a slower path — the kind of silent degradation that a functional smoke test passes and a throughput benchmark catches. This is why the readiness check has to be done at the runtime and toolchain layer, not at the “does it boot” layer. The discipline mirrors what we describe for getting the OpenCL runtime and SDK in place on Linux for ML inference: installing the packages is the easy half; confirming the runtime actually drives your target device at the capability level you need is the half that decides the outcome. Because Intel’s version matrices move, we treat the specific numbers as a per-evaluation lookup rather than a fact to memorise. The stable claim is the structure: three versioned layers, checked together, against one workload class. Can I run OpenCL or SYCL without rewriting my memory model? This is where the portability promise gets tested, and it maps directly onto the broader CUDA vs OpenCL porting decision that any team leaving the NVIDIA-only path has to make. For an existing OpenCL codebase, Arc is genuinely a target that Intel’s runtime supports, and a well-written OpenCL program that already avoids vendor-specific extensions can often run without a memory-model rewrite — OpenCL’s buffer and queue semantics are the same across vendors by design. The catch is performance, not correctness: kernels tuned for another vendor’s memory hierarchy and subgroup width may run correctly on Arc while leaving throughput on the table until they are retuned. For SYCL, the situation is more favourable in one sense and more version-sensitive in another. SYCL through Intel’s DPC++ compiler is a first-class path to Arc, so you are on the toolchain’s home turf. But SYCL’s Unified Shared Memory model and its device-selection behaviour interact with the runtime version, so the same source can behave differently across oneAPI releases on the same card. The honest framing is that you can usually avoid a memory-model rewrite, but you cannot avoid a retune-and-verify pass — and performance parity is a per-workload measurement, not a guarantee that comes with the API. If you are choosing between the two APIs as your portability layer, the trade-offs in what OpenCL vs CUDA means when porting AI workloads across GPUs apply directly to the Arc decision. How mature is oneAPI compute on Arc for ML inference vs display? The maturity gap between use cases is the single most important thing to internalise. Display and hardware video decode on Arc under Linux reach production-usable status early, riding the kernel graphics driver. Machine-learning inference through oneAPI, oneDNN, and the SYCL runtime sits at the top of the stack and matures later and more unevenly — a specific operator, data type, or model class may be well-optimised while an adjacent one is not yet. Running an open model on Intel hardware is a concrete illustration of this: what it takes to get DeepSeek running on Intel hardware in practice is a runtime-and-toolchain question, not a “does the GPU exist to the OS” question. For inference specifically, the honest readiness statement is conditional: oneAPI compute on Arc is viable for inference workloads whose operator set and precision are covered by the oneDNN and library versions in your chosen oneAPI release, and it should be benchmarked, not assumed, for anything at the edge of that coverage. This is an observed pattern from working across heterogeneous targets, not a fixed maturity percentage — the coverage boundary moves with every release. How should Arc readiness factor into a 3-year hardware roadmap? The decision framing that keeps teams out of trouble is to treat Arc Linux readiness as a per-layer, per-workload verdict that feeds the roadmap, rather than a binary “Arc is / isn’t a Linux GPU.” Use this rubric before committing hardware budget: Name the layer you depend on. Display and video → kernel driver, matures early, low risk. Portable compute → runtime + toolchain, later maturity, verify before committing. Pin the version tuple. Record the kernel version, intel-compute-runtime / Level Zero version, and oneAPI/SYCL release you intend to standardise on. A readiness verdict without these three numbers is not a verdict. Benchmark the workload class, not the card. Run your actual operator set and precision on the target tuple. A passing functional test is not a performance verdict — silent fallback is the failure mode here. Check the coverage boundary against your 3-year model roadmap. If your planned workloads sit at the edge of current oneDNN/oneMKL coverage, budget for the runtime to catch up — or don’t commit until it has. Re-verify on every stack bump. The version tuple is a moving target; the verdict has a shelf life. That is the difference between “it should work” and a defensible hardware plan. This layered readiness verdict is exactly the kind of input a GPU performance audit folds into its hardware-diversity dimension: before recommending a portable API path onto Arc, the audit checks whether the target compute runtime is mature enough for the specific workload, so the portability decision rests on a measured runtime verdict rather than a marketing support checkbox. FAQ How should you think about Intel Arc Linux support in practice? Intel Arc Linux support is not a single yes/no state. It is three stacked layers — the kernel graphics driver (i915/Xe), the userspace compute runtime (Level Zero and OpenCL), and the oneAPI/SYCL toolchain — each with its own version cadence and maturity. In practice, “supported” means different things depending on which layer your workload depends on, so the useful question is which layer you need, not whether the card boots. Which layer of the stack does “supported” actually refer to, and why does the distinction matter? It refers to whichever layer the speaker has in mind, which is usually the kernel graphics driver — the one that makes the desktop and video work and matures earliest. That distinction matters because your compute workload rides the runtime and the toolchain, the two upper layers, which mature later and more unevenly. A mature kernel driver tells you almost nothing about whether your OpenCL or SYCL workload runs at competitive performance. What Linux kernel and driver versions do I need for Intel Arc GPU compute to be usable? You need three things aligned: a kernel new enough to enumerate your specific Arc card as a compute device (which involves the i915-to-Xe driver transition), an intel-compute-runtime recent enough to expose the card’s full compute capability, and a oneAPI release whose support matrix lists your card. Because Intel’s version matrices move with each release, treat the exact numbers as a per-evaluation lookup; the stable requirement is that all three layers are checked together against your workload class. Can I run OpenCL or SYCL workloads on Intel Arc under Linux without rewriting my memory model, and how does performance compare? Usually yes for correctness — OpenCL buffer/queue semantics and SYCL’s memory model are portable by design, so a codebase avoiding vendor-specific extensions can often run without a rewrite. The catch is performance: kernels tuned for another vendor’s memory hierarchy may run correctly but below the hardware ceiling until retuned, and SYCL behaviour can shift across oneAPI releases. Plan for a retune-and-verify pass, and treat performance parity as a per-workload measurement rather than an API guarantee. How mature is oneAPI/Level Zero compute on Arc for machine-learning inference versus display and video use? Display and hardware video decode reach production-usable status early because they ride the kernel graphics driver. ML inference through oneAPI, oneDNN, and the SYCL runtime sits at the top of the stack and matures later and unevenly — a given operator or precision may be well-optimised while an adjacent one is not. Inference is viable when your operator set and precision are covered by your oneAPI release’s libraries, and it should be benchmarked rather than assumed at the edge of that coverage. How should Intel Arc Linux readiness factor into a portability-focused GPU API decision and a 3-year hardware roadmap? Treat it as a per-layer, per-workload verdict rather than a binary. Name the layer you depend on, pin the version tuple (kernel, compute runtime, oneAPI/SYCL release), benchmark your actual workload class on that tuple, check the coverage boundary against your planned model roadmap, and re-verify on every stack bump. That converts “it should work” into a defensible hardware plan that a portability decision and a GPU performance audit can rest on. The question worth carrying forward is not “does Arc support Linux” but “which version tuple, verified against which workload class, makes Arc a defensible line in a three-year roadmap” — because portability is decided at the runtime layer you actually call, not the support checkbox you were shown.
