On Tue, Aug 29, 2023 at 12:30:03PM -0400, Rodrigo Vivi wrote: > The consensus is for individual drivers VM_BIND uapis with > the GPUVA helpers that are already implemented and merged > upstream. > > The merged GPUVA documentation also establish some overall > rules for the locking to be followed by the drivers. Danilo, do you agree with this? if nothing is missing on that front, could you please ack this patch? > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > --- > Documentation/gpu/rfc/xe.rst | 34 +++++++++++++++++----------------- > 1 file changed, 17 insertions(+), 17 deletions(-) > > diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst > index bf60c5c82d0e..a115526c03e0 100644 > --- a/Documentation/gpu/rfc/xe.rst > +++ b/Documentation/gpu/rfc/xe.rst > @@ -106,23 +106,6 @@ 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. > > -DRM_VM_BIND > ------------ > -Nouveau, and Xe are all implementing ‘VM_BIND’ and new ‘Exec’ uAPIs in order to > -fulfill the needs of the modern uAPI. Xe merge should *not* be blocked on the > -development of a common new drm_infrastructure. However, the Xe team needs to > -engage with the community to explore the options of a common API. > - > -As a key measurable result, the DRM_VM_BIND needs to be documented in this file > -below, or this entire block deleted if the consensus is for independent drivers > -vm_bind ioctls. > - > -Although having a common DRM level IOCTL for VM_BIND is not a requirement to get > -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. > - > ASYNC VM_BIND > ------------- > Although having a common DRM level IOCTL for VM_BIND is not a requirement to get > @@ -230,3 +213,20 @@ Later, when we are in-tree, the goal is to collaborate with devcoredump > infrastructure with overall possible improvements, like multiple file support > for better organization of the dumps, snapshot support, dmesg extra print, > and whatever may make sense and help the overall infrastructure. > + > +DRM_VM_BIND > +----------- > +Nouveau, and Xe are all implementing ‘VM_BIND’ and new ‘Exec’ uAPIs in order to > +fulfill the needs of the modern uAPI. Xe merge should *not* be blocked on the > +development of a common new drm_infrastructure. However, the Xe team needs to > +engage with the community to explore the options of a common API. > + > +As a key measurable result, the DRM_VM_BIND needs to be documented in this file > +below, or this entire block deleted if the consensus is for independent drivers > +vm_bind ioctls. > + > +Although having a common DRM level IOCTL for VM_BIND is not a requirement to get > +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. > -- > 2.41.0 >
