Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Danilo Krummrich <dakr@redhat.com>
Cc: daniel.vetter@ffwll.ch, intel-xe@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH 3/4] drm/doc/rfc: Mark DRM_VM_BIND as complete.
Date: Wed, 6 Sep 2023 13:57:15 -0400	[thread overview]
Message-ID: <ZPi9e23qxScmLEPC@intel.com> (raw)
In-Reply-To: <8d38c7a4-03de-a9ed-13a2-3044352392e9@redhat.com>

On Mon, Sep 04, 2023 at 11:32:30PM +0200, Danilo Krummrich wrote:
> Hi Rodrigo,
> 
> On 8/31/23 21:10, Rodrigo Vivi wrote:
> > 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?
> 
> I agree with the above, hence:
> 
> Acked-by: Danilo Krummrich <dakr@redhat.com>
> 
> However, the documentation below seems to be more about a common DRM_VM_BIND IOCTL?
> I guess your commit refers to the end where it talks about common VM_BIND helpers.

Yes, it was about a common vm_bind helpers. But if the consensus is to go with
the individual drivers vm_bind uapis with common gpu_va, this common drm_vm_bind
talk makes no sense anymore. So we can end the talks about it.

> 
> Otherwise the patch is moving the "DRM_VM_BIND" paragraph somewhere below the
> "Dev_coredump"paragraph. Is there some kind of "Done-Section" I'm missing?

Yes, it moves to a new
+Xe – Pre-Merge Goals - Completed
+================================

added on patch 2 with devcoredump:

https://lore.kernel.org/all/20230829163005.54067-2-rodrigo.vivi@intel.com/


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

  reply	other threads:[~2023-09-06 17:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-29 16:30 [Intel-xe] [PATCH 1/4] drm/doc/rfc: No STAGING out of drivers/staging Rodrigo Vivi
2023-08-29 16:30 ` [Intel-xe] [PATCH 2/4] drm/doc/rfc: Mark Dev_coredump as completed Rodrigo Vivi
2023-08-29 16:30 ` [Intel-xe] [PATCH 3/4] drm/doc/rfc: Mark DRM_VM_BIND as complete Rodrigo Vivi
2023-08-31 19:10   ` Rodrigo Vivi
2023-09-04 21:32     ` Danilo Krummrich
2023-09-06 17:57       ` Rodrigo Vivi [this message]
2023-08-29 16:30 ` [Intel-xe] [PATCH 4/4] drm/doc/rfc: Mark GPU VA " Rodrigo Vivi
2023-08-31 19:17   ` Rodrigo Vivi
2023-09-04 21:39     ` Danilo Krummrich
2023-09-06 18:03       ` Rodrigo Vivi
2023-08-29 16:44 ` [Intel-xe] ✗ CI.Patch_applied: failure for series starting with [1/4] drm/doc/rfc: No STAGING out of drivers/staging Patchwork
2023-08-29 17:35 ` [Intel-xe] [PATCH 1/4] " Lucas De Marchi
2023-08-31  8:31 ` Daniel Vetter
2023-08-31 19:08   ` Rodrigo Vivi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZPi9e23qxScmLEPC@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=dakr@redhat.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox