dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Maíra Canal" <mcanal@igalia.com>
Cc: Dave Airlie <airlied@gmail.com>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: xe vs amdgpu userptr handling
Date: Thu, 8 Feb 2024 17:22:07 +0100	[thread overview]
Message-ID: <ZcT_r8XfXQOmIQWo@phenom.ffwll.local> (raw)
In-Reply-To: <0c4da8bd-452a-4ba5-9c4c-582cbc7b5dec@igalia.com>

On Wed, Feb 07, 2024 at 08:08:42AM -0300, Maíra Canal wrote:
> Adding another point to this discussion, would it make sense to somehow
> create a generic structure that all drivers, including shmem drivers, could
> use it?


So the issue is a bit that at least the userptr for shmem drivers I've
seen all just use pin_user_pages(FOLL_LONGTERM), which nails the memory in
place and makes it unshrinkable. I think that would be fairly easy to
integrate into shmem helpers, and might already be a win (to catch stuff
like userspace trying to share these). This memory probably should be
accounted against mlock rlimit, but that's an entire different can of
worms.

Going full dynamic cross driver is a lot more infrastructure, because your
command submission path needs to substantially change. I think that only
makes when you have a lot more cross-driver code and not just the bare
minimum buffer helpers, and I think gpuvm might be a good place to fit.
Since that already has the concepts around "prepare this entire vm", and
extending that is a lot more reasonable than building an entire new thing.

I'm on board with Dave and agree that we really shouldn't have a diverse
bouqet of driver specific implementations of all this, but I think
fundamentally we will end up with the above two flavours for various
reasons.

So which userptr do you mean?

Cheers, Sima

> 
> Best Regards,
> - Maíra
> 
> On 2/7/24 03:56, Dave Airlie wrote:
> > I'm just looking over the userptr handling in both drivers, and of
> > course they've chosen different ways to represent things. Again this
> > is a divergence that is just going to get more annoying over time and
> > eventually I'd like to make hmm/userptr driver independent as much as
> > possible, so we get consistent semantics in userspace.
> > 
> > AFAICS the main difference is that amdgpu builds the userptr handling
> > inside a GEM object in the kernel, whereas xe doesn't bother creating
> > a holding object and just handles things directly in the VM binding
> > code.
> > 
> > Is this just different thinking at different times here?
> > like since we have VM BIND in xe, it made sense not to bother creating
> > a gem object for userptrs?
> > or is there some other advantages to going one way or the other?
> > 
> > Dave.

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

      parent reply	other threads:[~2024-02-08 16:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-07  6:56 xe vs amdgpu userptr handling Dave Airlie
2024-02-07 11:08 ` Maíra Canal
2024-02-08  0:36   ` Dave Airlie
2024-02-08  6:30     ` Christian König
2024-02-08  9:38       ` Thomas Hellström
2024-02-08  9:43         ` Thomas Hellström
2024-02-08 11:08           ` Christian König
2024-02-08 11:25             ` Thomas Hellström
2024-02-08 16:22   ` Daniel Vetter [this message]

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=ZcT_r8XfXQOmIQWo@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mcanal@igalia.com \
    /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