Lines Matching +full:0 +full:xe

2 Xe – Merge Acceptance Plan
4 Xe is a new driver for Intel GPUs that supports both integrated and
5 discrete platforms starting with Tiger Lake (first Intel Xe Architecture).
7 This document aims to establish a merge plan for the Xe, by writing down clear
10 Xe – Overview
12 The main motivation of Xe is to have a fresh base to work from that is
38 https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next)
40 Xe – Platforms
42 Currently, Xe is already functional and has experimental support for multiple
47 During a transition period, platforms will be supported by both Xe and i915.
51 For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead of
55 i915.force_probe=!5690 xe.force_probe=5690
64 current platforms that are already out of this protection. Xe support will be
68 When the time comes for Xe, the protection will be lifted on Xe and kept in i915.
70 Xe driver will be protected with both STAGING Kconfig and force_probe. Changes in
74 that will be productized with Xe driver, but not with i915.
76 Xe – Pre-Merge Goals
81 Xe primarily uses Firmware based scheduling (GuC FW). However, it will use
87 Deeper changes to drm_scheduler should *not* be required to get Xe accepted, but
88 some consensus needs to be reached between Xe and other community drivers that
92 As a key measurable result, the patch series introducing Xe itself shall not
99 Two main goals of Xe are meeting together here:
108 upstream and the port of Xe towards GPUVA is already ongoing.
110 As a key measurable result, Xe needs to be aligned with the GPU VA and working in
111 our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA
113 maintainers to go along with the first Xe pull request towards drm-next.
117 Nouveau, and Xe are all implementing ‘VM_BIND’ and new ‘Exec’ uAPIs in order to
118 fulfill the needs of the modern uAPI. Xe merge should *not* be blocked on the
119 development of a common new drm_infrastructure. However, the Xe team needs to
127 Xe merged, it is mandatory to enforce the overall locking scheme for all major
135 Xe merged, it is mandatory to have a consensus with other drivers and Mesa.
157 then moved to another more specific document or at Xe level or at DRM level.
178 The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with
180 drm driver, including Xe, could re-use and add their own individual needs on top
190 xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs'
191 depending on the build target. The goal is to refactor both Xe and i915/display
195 However, display code should not gate the acceptance of Xe in upstream. Xe
197 from the first pull request of Xe towards drm-next. The expectation is that when
205 If that happens, Xe needs to change and incorporate the changes in the driver.
208 place waiting for Xe to get merged.
213 this document and the Xe driver prepared for the changes, if necessary.
218 Xe needs to align with other drivers on the way that the error states are
219 dumped, avoiding a Xe only error_state solution. The goal is to use devcoredump
223 As the key measurable result, Xe driver needs to provide GPU snapshots captured
232 Xe – uAPI high level overview