[Intel-xe] [PATCH 4/4] drm/doc/rfc: Mark GPU VA as complete.

[Rodrigo Vivi]

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

> 
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
> ---
>  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
>