gpu/rfc/xe.rst

8 pre-merge goals, in order to avoid unnecessary delays.
29 As for the power management area, the goal is to have a much-simplified support
30 for the system suspend states (S-states), PCI device suspend states (D-states),
31 GPU/Render suspend states (R-states) and frequency management. It should leverage
32 as much as possible all the existent PCI-subsystem infrastructure (pm and
33 runtime_pm) and underlying firmware components such PCODE and GuC for the power
38 https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next)
49 official and by-default probe at a given time.
60 only removed when the support for the platform and the uAPI are stable. Stability
68 When the time comes for Xe, the protection will be lifted on Xe and kept in i915.
76 Xe – Pre-Merge Goals
80 -------------
83 resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is
84 not yet prepared to handle the 1-to-1 relationship between drm_gpu_scheduler and
94 through drm-misc. This, by itself, already includes the reach of an agreement for
98 ------
112 related patch should be independent and present on dri-devel or acked by
113 maintainers to go along with the first Xe pull request towards drm-next.
116 -----------
133 -------------
145 -------------------------------
163  * Locking, including the page-faulting case.
169 the time comes.
172 --------------------------------------------------------
174 contexts, with the minimal scaffolding for preempt-ctx fences (probably on the
178 The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with
179 this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any
180 drm driver, including Xe, could re-use and add their own individual needs on top
183 This is a non-blocker item since the driver without the support for the long
187 -----------------------------
193 that display can already be part of the initial pull request towards drm-next.
197 from the first pull request of Xe towards drm-next. The expectation is that when
198 both drivers are part of the drm-tip, the introduction of cleaner patches will be
202 --------
210 This item ties into the GPUVA, VM_BIND, and even long-running compute support.
216 ------------
224 at hang time through devcoredump, but without depending on any core modification
227 Later, when we are in-tree, the goal is to collaborate with devcoredump