Skip to content

Commit e4a0fbd

Browse files
committed
drm/doc/rfc: Mark GPU VA as complete.
Nouveau has landed the GPU VA helpers, support and documentation already and Xe is already using the upstream GPU VA. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/commit/ea4ae69e66b2940107e74f240ecb9dae87bf1ff1 Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/commits/drm-xe-next?ref_type=heads Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230829163005.54067-4-rodrigo.vivi@intel.com
1 parent 3d06add commit e4a0fbd

1 file changed

Lines changed: 18 additions & 18 deletions

File tree

Documentation/gpu/rfc/xe.rst

Lines changed: 18 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -88,24 +88,6 @@ depend on any other patch touching drm_scheduler itself that was not yet merged
8888
through drm-misc. This, by itself, already includes the reach of an agreement for
8989
uniform 1 to 1 relationship implementation / usage across drivers.
9090

91-
GPU VA
92-
------
93-
Two main goals of Xe are meeting together here:
94-
95-
1) Have an uAPI that aligns with modern UMD needs.
96-
97-
2) Early upstream engagement.
98-
99-
RedHat engineers working on Nouveau proposed a new DRM feature to handle keeping
100-
track of GPU virtual address mappings. This is still not merged upstream, but
101-
this aligns very well with our goals and with our VM_BIND. The engagement with
102-
upstream and the port of Xe towards GPUVA is already ongoing.
103-
104-
As a key measurable result, Xe needs to be aligned with the GPU VA and working in
105-
our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA
106-
related patch should be independent and present on dri-devel or acked by
107-
maintainers to go along with the first Xe pull request towards drm-next.
108-
10991
ASYNC VM_BIND
11092
-------------
11193
Although having a common DRM level IOCTL for VM_BIND is not a requirement to get
@@ -230,3 +212,21 @@ Xe merged, it is mandatory to enforce the overall locking scheme for all major
230212
structs and list (so vm and vma). So, a consensus is needed, and possibly some
231213
common helpers. If helpers are needed, they should be also documented in this
232214
document.
215+
216+
GPU VA
217+
------
218+
Two main goals of Xe are meeting together here:
219+
220+
1) Have an uAPI that aligns with modern UMD needs.
221+
222+
2) Early upstream engagement.
223+
224+
RedHat engineers working on Nouveau proposed a new DRM feature to handle keeping
225+
track of GPU virtual address mappings. This is still not merged upstream, but
226+
this aligns very well with our goals and with our VM_BIND. The engagement with
227+
upstream and the port of Xe towards GPUVA is already ongoing.
228+
229+
As a key measurable result, Xe needs to be aligned with the GPU VA and working in
230+
our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA
231+
related patch should be independent and present on dri-devel or acked by
232+
maintainers to go along with the first Xe pull request towards drm-next.

0 commit comments

Comments
 (0)