From: Dave Airlie <airlied@gmail.com>
To: Oded Gabbay <ogabbay@kernel.org>
Cc: Danilo Krummrich <dakr@redhat.com>,
Donald Robson <Donald.Robson@imgtec.com>,
daniel@ffwll.ch, tzimmermann@suse.de, mripard@kernel.org,
corbet@lwn.net, christian.koenig@amd.com, bskeggs@redhat.com,
Liam.Howlett@oracle.com, matthew.brost@intel.com,
boris.brezillon@collabora.com, alexdeucher@gmail.com,
bagasdotme@gmail.com, willy@infradead.org, jason@jlekstrand.net,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
linux-doc@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH drm-next v5 00/14] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI
Date: Tue, 20 Jun 2023 17:13:31 +1000 [thread overview]
Message-ID: <CAPM=9tyv5Fje0iL0-2oJQBKEsg-nc-YV9q4BSg5SwnBvGvrzDw@mail.gmail.com> (raw)
In-Reply-To: <CAFCwf11OwnoxPWHuS_55OXKE7wfHH++1Bk_37DATeCiT07GtMQ@mail.gmail.com>
On Tue, 20 Jun 2023 at 17:06, Oded Gabbay <ogabbay@kernel.org> wrote:
>
> On Tue, Jun 20, 2023 at 7:05 AM Dave Airlie <airlied@gmail.com> wrote:
> >
> > Since this is feature is nouveau only currently and doesn't disturb
> > the current nouveau code paths, I'd like to try and get this work in
> > tree so other drivers can work from it.
> >
> > If there are any major objections to this, I'm happy to pull it back
> > out again, but I'd like to get some acks/rb in the next couple of days
> > in order to land some of it.
> >
> > Dave.
> >
> >
> > >
> > > forgot to add your email address to the patch series - sorry about that.
> > >
> > > This series (v5) contains the Documentation changes you requested.
> > >
> > > - Danilo
> > >
> > > On 6/20/23 02:42, Danilo Krummrich wrote:
> > > > This patch series provides a new UAPI for the Nouveau driver in order to
> > > > support Vulkan features, such as sparse bindings and sparse residency.
> > > >
> > > > Furthermore, with the DRM GPUVA manager it provides a new DRM core feature to
> > > > keep track of GPU virtual address (VA) mappings in a more generic way.
> > > >
> > > > The DRM GPUVA manager is indented to help drivers implement userspace-manageable
> > > > GPU VA spaces in reference to the Vulkan API. In order to achieve this goal it
> > > > serves the following purposes in this context.
> > > >
> > > > 1) Provide infrastructure to track GPU VA allocations and mappings,
> > > > making use of the maple_tree.
> > > >
> > > > 2) Generically connect GPU VA mappings to their backing buffers, in
> > > > particular DRM GEM objects.
> Will this manager be able to connect GPU VA mappings to host memory
> allocations (aka user pointers) ?
>
> I only skimmed over the uapi definitions, but from that quick glance I
> saw you can only pass a (gem) handle to the vm bind uapi.
>
> I think it is an important feature because you don't want to have two
> GPU VA managers running in your driver (if that's even possible).
> Maybe we should at least try to make sure the uapi is/will be
> compatible with such an extension.
>
I think that would have to be a new uAPI entry point anyways, since
managing user ptrs is extra, but the uAPI is nouveau specific and
nouveau has no hostptr support as of now.
The gpuva manager is kernel internal, I think adding host ptr tracking
is useful, but I don't think it's a blocker right now.
One of the reasons I'd like to get this in the tree is to add things
like that instead of overloading this initial patchset with feature
creep.
Dave.
next prev parent reply other threads:[~2023-06-20 7:13 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-20 0:42 Danilo Krummrich
2023-06-19 23:06 ` Danilo Krummrich
2023-06-20 4:05 ` Dave Airlie
2023-06-20 7:06 ` Oded Gabbay
2023-06-20 7:13 ` Dave Airlie [this message]
2023-06-20 7:34 ` Oded Gabbay
2023-06-20 0:42 ` [PATCH drm-next v5 01/14] drm: execution context for GEM buffers v4 Danilo Krummrich
2023-06-20 0:42 ` [PATCH drm-next v5 02/14] maple_tree: split up MA_STATE() macro Danilo Krummrich
2023-06-20 0:42 ` [PATCH drm-next v5 03/14] drm: manager to keep track of GPUs VA mappings Danilo Krummrich
2023-06-20 3:00 ` kernel test robot
2023-06-20 3:32 ` kernel test robot
2023-06-20 4:54 ` Christoph Hellwig
2023-06-20 6:45 ` Christian König
2023-06-20 12:23 ` Danilo Krummrich
2023-06-22 13:54 ` Christian König
2023-06-22 14:22 ` Danilo Krummrich
2023-06-22 14:42 ` Christian König
2023-06-22 15:04 ` Danilo Krummrich
2023-06-22 15:07 ` Danilo Krummrich
2023-06-23 2:24 ` Matthew Brost
2023-06-23 7:16 ` Christian König
2023-06-23 13:55 ` Danilo Krummrich
2023-06-23 15:34 ` Christian König
2023-06-26 22:38 ` Dave Airlie
2023-06-21 18:58 ` Donald Robson
2023-06-20 0:42 ` [PATCH drm-next v5 04/14] drm: debugfs: provide infrastructure to dump a DRM GPU VA space Danilo Krummrich
2023-06-20 0:42 ` [PATCH drm-next v5 05/14] drm/nouveau: new VM_BIND uapi interfaces Danilo Krummrich
2023-06-20 0:42 ` [PATCH drm-next v5 06/14] drm/nouveau: get vmm via nouveau_cli_vmm() Danilo Krummrich
2023-06-20 0:42 ` [PATCH drm-next v5 07/14] drm/nouveau: bo: initialize GEM GPU VA interface Danilo Krummrich
2023-06-20 0:42 ` [PATCH drm-next v5 08/14] drm/nouveau: move usercopy helpers to nouveau_drv.h Danilo Krummrich
2023-06-20 0:42 ` [PATCH drm-next v5 09/14] drm/nouveau: fence: separate fence alloc and emit Danilo Krummrich
2023-06-21 2:26 ` kernel test robot
2023-06-20 0:42 ` [PATCH drm-next v5 10/14] drm/nouveau: fence: fail to emit when fence context is killed Danilo Krummrich
2023-06-20 0:42 ` [PATCH drm-next v5 11/14] drm/nouveau: chan: provide nouveau_channel_kill() Danilo Krummrich
2023-06-20 0:42 ` [PATCH drm-next v5 12/14] drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm Danilo Krummrich
2023-06-20 0:42 ` [PATCH drm-next v5 13/14] drm/nouveau: implement new VM_BIND uAPI Danilo Krummrich
2023-06-20 0:42 ` [PATCH drm-next v5 14/14] drm/nouveau: debugfs: implement DRM GPU VA debugfs Danilo Krummrich
2023-06-20 9:25 ` [PATCH drm-next v5 00/14] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI Boris Brezillon
2023-06-20 12:46 ` Danilo Krummrich
2023-06-22 13:01 ` Boris Brezillon
2023-06-22 13:58 ` Danilo Krummrich
2023-06-22 15:19 ` Boris Brezillon
2023-06-22 15:27 ` Danilo Krummrich
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='CAPM=9tyv5Fje0iL0-2oJQBKEsg-nc-YV9q4BSg5SwnBvGvrzDw@mail.gmail.com' \
--to=airlied@gmail.com \
--cc=Donald.Robson@imgtec.com \
--cc=Liam.Howlett@oracle.com \
--cc=alexdeucher@gmail.com \
--cc=bagasdotme@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=bskeggs@redhat.com \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=dakr@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jason@jlekstrand.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ogabbay@kernel.org \
--cc=tzimmermann@suse.de \
--cc=willy@infradead.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