gpu/rfc/xe.rst

4 Xe is a new driver for Intel GPUs that supports both integrated and
7 This document aims to establish a merge plan for the Xe, by writing down clear
8 pre-merge goals, in order to avoid unnecessary delays.
12 The main motivation of Xe is to have a fresh base to work from that is
18 This is also an opportunity to start from the beginning with a clean uAPI that is
20 this reason, the memory model is solely based on GPU Virtual Address space
26 The new driver leverages a lot from i915. As for display, the intent is to share
27 the display code with the i915 driver so that there is maximum reuse there.
29 As for the power management area, the goal is to have a much-simplified support
42 Currently, Xe is already functional and has experimental support for multiple
51 For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead of
59 force_probe parameter while the driver is under development. This protection is
75 In order to share the display code with the i915 driver so that there is maximum
76 reuse, the i915/display/ code is built twice, once for i915.ko and then for
77 xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs'
78 depending on the build target. The goal is to refactor both Xe and i915/display
84 from the first pull request of Xe towards drm-next. The expectation is that when
98 Helper to make dma_resv locking for a big number of buffers is getting removed in
101 The goal is to engage with the Community to understand if the best approach is to
113 With multiple drivers currently introducing support to VM_BIND, the goal is to
115 extent this is already getting addressed itself with the GPUVA where likely the
133 The document is now included in the drm documentation :doc:`here </gpu/drm-vm-bind-async>`.
144 Although having a common DRM level IOCTL for VM_BIND is not a requirement to get
145 Xe merged, it is mandatory to have a consensus with other drivers and Mesa.
158 resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is
179 The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with
182 in a next stage. However, this should not block the initial merge.
188 dumped, avoiding a Xe only error_state solution. The goal is to use devcoredump
196 Later, when we are in-tree, the goal is to collaborate with devcoredump
204 fulfill the needs of the modern uAPI. Xe merge should *not* be blocked on the
209 below, or this entire block deleted if the consensus is for independent drivers
212 Although having a common DRM level IOCTL for VM_BIND is not a requirement to get
213 Xe merged, it is mandatory to enforce the overall locking scheme for all major
214 structs and list (so vm and vma). So, a consensus is needed, and possibly some
227 track of GPU virtual address mappings. This is still not merged upstream, but
229 upstream and the port of Xe towards GPUVA is already ongoing.