Commit 16805e99 authored by Rodrigo Vivi's avatar Rodrigo Vivi

drm/doc/rfc: Move Xe 'ASYNC VM_BIND' to the 'completed' section

As already indicated in this block, the consensus was already
reached out and documented as:
The ASYNC VM_BIND document </gpu/drm-vm-bind-async>

However this was item was not moved to the completed section.
Let's move and clean up the WIP block.
Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231201042158.80009-4-rodrigo.vivi@intel.comAcked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
parent 0e2e6c49
...@@ -70,18 +70,6 @@ When the time comes for Xe, the protection will be lifted on Xe and kept in i915 ...@@ -70,18 +70,6 @@ When the time comes for Xe, the protection will be lifted on Xe and kept in i915
Xe – Pre-Merge Goals - Work-in-Progress Xe – Pre-Merge Goals - Work-in-Progress
======================================= =======================================
ASYNC VM_BIND
-------------
Although having a common DRM level IOCTL for VM_BIND is not a requirement to get
Xe merged, it is mandatory to have a consensus with other drivers and Mesa.
It needs to be clear how to handle async VM_BIND and interactions with userspace
memory fences. Ideally with helper support so people don't get it wrong in all
possible ways.
As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of
various flavors, error handling and sample API suggestions are documented in
:doc:`The ASYNC VM_BIND document </gpu/drm-vm-bind-async>`.
Userptr integration and vm_bind Userptr integration and vm_bind
------------------------------- -------------------------------
Different drivers implement different ways of dealing with execution of userptr. Different drivers implement different ways of dealing with execution of userptr.
...@@ -151,6 +139,18 @@ Xe – uAPI high level overview ...@@ -151,6 +139,18 @@ Xe – uAPI high level overview
Xe – Pre-Merge Goals - Completed Xe – Pre-Merge Goals - Completed
================================ ================================
ASYNC VM_BIND
-------------
Although having a common DRM level IOCTL for VM_BIND is not a requirement to get
Xe merged, it is mandatory to have a consensus with other drivers and Mesa.
It needs to be clear how to handle async VM_BIND and interactions with userspace
memory fences. Ideally with helper support so people don't get it wrong in all
possible ways.
As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of
various flavors, error handling and sample API suggestions are documented in
:doc:`The ASYNC VM_BIND document </gpu/drm-vm-bind-async>`.
Drm_scheduler Drm_scheduler
------------- -------------
Xe primarily uses Firmware based scheduling (GuC FW). However, it will use Xe primarily uses Firmware based scheduling (GuC FW). However, it will use
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment