Re: [PATCH 4/4] drm/doc/rfc: Mark GPU VA as complete.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/31/23 21:17, Rodrigo Vivi wrote:
On Tue, Aug 29, 2023 at 12:30:04PM -0400, Rodrigo Vivi wrote:
Nouveau has landed the GPU VA helpers, support and documentation
already and Xe is already using the upstream GPU VA.

Danilo, although this is more on the Xe side and I wouldn't ask you
to review our code entirely, I'd like to get your ack here as Daniel
recommended. Meaning that we are aligned there and not creating any
change on top of GPU VA. Xe is currently using GPU VA directly without
any customization.

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

Acked-by: Danilo Krummrich <dakr@xxxxxxxxxx>

Just one note: If we end up to agree on [1] few more adjustments are needed.

Otherwise, same as the other commit, where is the paragraph going?

- Danilo

[1] https://lore.kernel.org/dri-devel/202308221050.kTj8uFMA-lkp@xxxxxxxxx/T/#m7f3b5a7ff70723332adeea32671578cb95c62f7c



Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
---
  Documentation/gpu/rfc/xe.rst | 36 ++++++++++++++++++------------------
  1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst
index a115526c03e0..b67f8e6a1825 100644
--- a/Documentation/gpu/rfc/xe.rst
+++ b/Documentation/gpu/rfc/xe.rst
@@ -88,24 +88,6 @@ depend on any other patch touching drm_scheduler itself that was not yet merged
  through drm-misc. This, by itself, already includes the reach of an agreement for
  uniform 1 to 1 relationship implementation / usage across drivers.
-GPU VA
-------
-Two main goals of Xe are meeting together here:
-
-1) Have an uAPI that aligns with modern UMD needs.
-
-2) Early upstream engagement.
-
-RedHat engineers working on Nouveau proposed a new DRM feature to handle keeping
-track of GPU virtual address mappings. This is still not merged upstream, but
-this aligns very well with our goals and with our VM_BIND. The engagement with
-upstream and the port of Xe towards GPUVA is already ongoing.
-
-As a key measurable result, Xe needs to be aligned with the GPU VA and working in
-our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA
-related patch should be independent and present on dri-devel or acked by
-maintainers to go along with the first Xe pull request towards drm-next.
-
  ASYNC VM_BIND
  -------------
  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
  structs and list (so vm and vma). So, a consensus is needed, and possibly some
  common helpers. If helpers are needed, they should be also documented in this
  document.
+
+GPU VA
+------
+Two main goals of Xe are meeting together here:
+
+1) Have an uAPI that aligns with modern UMD needs.
+
+2) Early upstream engagement.
+
+RedHat engineers working on Nouveau proposed a new DRM feature to handle keeping
+track of GPU virtual address mappings. This is still not merged upstream, but
+this aligns very well with our goals and with our VM_BIND. The engagement with
+upstream and the port of Xe towards GPUVA is already ongoing.
+
+As a key measurable result, Xe needs to be aligned with the GPU VA and working in
+our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA
+related patch should be independent and present on dri-devel or acked by
+maintainers to go along with the first Xe pull request towards drm-next.
--
2.41.0






[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux