Intel's Game Plan For Getting The Xe Linux Kernel Graphics Driver Upstreamed
For more than one year Intel's been working on developing the Xe Linux kernel graphics driver as a modern Direct Rendering Manager driver for Gen12 and newer integrated/discrete graphics. For recent hardware this is to replace the existing i915 kernel driver usage. The Intel open-source developers continue working toward the milestone of being able to submit this driver for mainlining in the upstream Linux kernel.
With the Xe kernel graphics driver the Intel engineers involved have been able to take a fresh design approach compared to the i915 kernel driver that's been built up organically over the past two decades. With the Xe driver they are just supporting Gen12 and newer so they don't need to worry about older Intel graphics hardware generations, they can focus on making use of modern kernel features, and with their user-space API they don't need to worry about backwards compatibility with the existing i915 uAPI limitations/challenges.
This week the Intel Linux engineers posted their latest merge plan for the Xe driver.
At the moment the Xe driver is considered functional and with "experimental" support for Tiger Lake and newer. Once the driver is upstreamed into the kernel, the plan is to maintain Gen12+ support still in i915. The Xe driver will be opt-in via the force_probe module parameter while one can similarly disable the i915 driver from loading for a given GPU. So for a few releases or however long it takes for the Xe driver to prove itself, users can switch over to Xe manually to help in testing the support.
In fact, the merge plan notes that for currently-released Intel hardware, i915 may continue being the default indefinitely: "In order to avoid user space regressions, i915 will continue to support all the current platforms that are already out of this protection. Xe support will be forever experimental and dependent on the usage of force_probe for these platforms."
Among the goals that the driver developers have before merging Xe is for sorting out DRM scheduler changes, GPU virtual address mapping changes to be upstreamed, DRM_VM_BIND, async VM_BIND, user pointer "userptr" integration and VM_BIND support, and better dealing with long-running compute workloads. The developers also want better display code integration/sharing with the i915 driver and devcoredump infrastructure for reporting error states.
Concurrently the Intel open-source engineers have been adding Xe kernel driver compatibility to their Mesa drivers as well as their Compute-Runtime stack for OpenCL and Level Zero. The Intel ANV Vulkan and Iris Gallium3D/OpenGL driver compatibility with Xe will hopefully be squared away for Mesa 23.2 so that once this driver is indeed mainlined, the user-space support is ready and in place.
Those interested in the latest efforts and plans around upstreaming the Xe driver can see their latest merge plan. Hopefully we'll manage to see the Xe driver mainlined into the Linux kernel -- in experimental form -- later this calendar year.
With the Xe kernel graphics driver the Intel engineers involved have been able to take a fresh design approach compared to the i915 kernel driver that's been built up organically over the past two decades. With the Xe driver they are just supporting Gen12 and newer so they don't need to worry about older Intel graphics hardware generations, they can focus on making use of modern kernel features, and with their user-space API they don't need to worry about backwards compatibility with the existing i915 uAPI limitations/challenges.
This week the Intel Linux engineers posted their latest merge plan for the Xe driver.
At the moment the Xe driver is considered functional and with "experimental" support for Tiger Lake and newer. Once the driver is upstreamed into the kernel, the plan is to maintain Gen12+ support still in i915. The Xe driver will be opt-in via the force_probe module parameter while one can similarly disable the i915 driver from loading for a given GPU. So for a few releases or however long it takes for the Xe driver to prove itself, users can switch over to Xe manually to help in testing the support.
In fact, the merge plan notes that for currently-released Intel hardware, i915 may continue being the default indefinitely: "In order to avoid user space regressions, i915 will continue to support all the current platforms that are already out of this protection. Xe support will be forever experimental and dependent on the usage of force_probe for these platforms."
Among the goals that the driver developers have before merging Xe is for sorting out DRM scheduler changes, GPU virtual address mapping changes to be upstreamed, DRM_VM_BIND, async VM_BIND, user pointer "userptr" integration and VM_BIND support, and better dealing with long-running compute workloads. The developers also want better display code integration/sharing with the i915 driver and devcoredump infrastructure for reporting error states.
Concurrently the Intel open-source engineers have been adding Xe kernel driver compatibility to their Mesa drivers as well as their Compute-Runtime stack for OpenCL and Level Zero. The Intel ANV Vulkan and Iris Gallium3D/OpenGL driver compatibility with Xe will hopefully be squared away for Mesa 23.2 so that once this driver is indeed mainlined, the user-space support is ready and in place.
Those interested in the latest efforts and plans around upstreaming the Xe driver can see their latest merge plan. Hopefully we'll manage to see the Xe driver mainlined into the Linux kernel -- in experimental form -- later this calendar year.
12 Comments