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

[Danilo Krummrich]

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 at redhat.com>

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@intel.com/T/#m7f3b5a7ff70723332adeea32671578cb95c62f7c

> 
>>
>> 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
>>
>