From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Danilo Krummrich <dakr@redhat.com>,
airlied@gmail.com, daniel@ffwll.ch, matthew.brost@intel.com,
sarah.walker@imgtec.com, donald.robson@imgtec.com,
boris.brezillon@collabora.com, christian.koenig@amd.com,
faith@gfxstrand.net
Cc: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH drm-misc-next v7 4/7] drm/gpuvm: add an abstraction for a VM / BO combination
Date: Tue, 31 Oct 2023 17:45:56 +0100 [thread overview]
Message-ID: <ab8f30452540171447118d64931e66da96b6e85e.camel@linux.intel.com> (raw)
In-Reply-To: <980754a3-7f5a-465e-88a9-62a40c82cae8@redhat.com>
On Tue, 2023-10-31 at 17:39 +0100, Danilo Krummrich wrote:
> On 10/31/23 12:25, Thomas Hellström wrote:
> > On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> > > Add an abstraction layer between the drm_gpuva mappings of a
> > > particular
> > > drm_gem_object and this GEM object itself. The abstraction
> > > represents
> > > a
> > > combination of a drm_gem_object and drm_gpuvm. The drm_gem_object
> > > holds
> > > a list of drm_gpuvm_bo structures (the structure representing
> > > this
> > > abstraction), while each drm_gpuvm_bo contains list of mappings
> > > of
> > > this
> > > GEM object.
> > >
> > > This has multiple advantages:
> > >
> > > 1) We can use the drm_gpuvm_bo structure to attach it to various
> > > lists
> > > of the drm_gpuvm. This is useful for tracking external and
> > > evicted
> > > objects per VM, which is introduced in subsequent patches.
> > >
> > > 2) Finding mappings of a certain drm_gem_object mapped in a
> > > certain
> > > drm_gpuvm becomes much cheaper.
> > >
> > > 3) Drivers can derive and extend the structure to easily
> > > represent
> > > driver specific states of a BO for a certain GPUVM.
> > >
> > > The idea of this abstraction was taken from amdgpu, hence the
> > > credit
> > > for
> > > this idea goes to the developers of amdgpu.
> > >
> > > Cc: Christian König <christian.koenig@amd.com>
> > > Signed-off-by: Danilo Krummrich <dakr@redhat.com>
> > > ---
> > > drivers/gpu/drm/drm_gpuvm.c | 335
> > > +++++++++++++++++++++--
> > > --
> > > drivers/gpu/drm/nouveau/nouveau_uvmm.c | 64 +++--
> > > include/drm/drm_gem.h | 32 +--
> > > include/drm/drm_gpuvm.h | 188 +++++++++++++-
> > > 4 files changed, 533 insertions(+), 86 deletions(-)
> >
> > That checkpatch.pl error still remains as well.
>
> I guess you refer to:
>
> ERROR: do not use assignment in if condition
> #633: FILE: drivers/gpu/drm/nouveau/nouveau_uvmm.c:1165:
> + if (!(op->gem.obj = obj))
>
> This was an intentional decision, since in this specific case it
> seems to
> be more readable than the alternatives.
>
> However, if we consider this to be a hard rule, which we never ever
> break,
> I'm fine changing it too.
With the errors, sooner or later they are going to start generate
patches to "fix" them. In this particular case also Xe CI is
complaining and abort building when I submit the Xe adaptation, so it'd
be good to be checkpatch.pl conformant IMHO.
Thanks,
Thomas
>
> >
> > Thanks,
> > Thomas
> >
>
next prev parent reply other threads:[~2023-10-31 16:47 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-23 20:16 [PATCH drm-misc-next v7 0/7] [RFC] DRM GPUVM features Danilo Krummrich
2023-10-23 20:16 ` [PATCH drm-misc-next v7 1/7] drm/gpuvm: convert WARN() to drm_WARN() variants Danilo Krummrich
2023-10-24 8:45 ` Christian König
2023-10-24 12:16 ` Danilo Krummrich
2023-10-31 10:08 ` Thomas Hellström
2023-10-31 16:47 ` Danilo Krummrich
2023-10-23 20:16 ` [PATCH drm-misc-next v7 2/7] drm/gpuvm: add common dma-resv per struct drm_gpuvm Danilo Krummrich
2023-10-23 20:16 ` [PATCH drm-misc-next v7 3/7] drm/gpuvm: add drm_gpuvm_flags to drm_gpuvm Danilo Krummrich
2023-10-23 20:16 ` [PATCH drm-misc-next v7 4/7] drm/gpuvm: add an abstraction for a VM / BO combination Danilo Krummrich
2023-10-31 10:32 ` Thomas Hellström
2023-10-31 11:45 ` Jani Nikula
2023-10-31 16:30 ` Danilo Krummrich
2023-10-31 16:50 ` Thomas Hellström
2023-10-31 17:43 ` Danilo Krummrich
2023-10-31 17:38 ` Danilo Krummrich
2023-11-01 16:38 ` Thomas Hellström
2023-11-01 17:21 ` Danilo Krummrich
2023-11-01 19:45 ` Thomas Hellström
2023-11-01 20:46 ` Danilo Krummrich
2023-10-31 11:25 ` Thomas Hellström
2023-10-31 16:39 ` Danilo Krummrich
2023-10-31 16:45 ` Thomas Hellström [this message]
2023-10-31 17:52 ` Danilo Krummrich
2023-11-01 9:41 ` Thomas Hellström
2023-11-01 9:56 ` Thomas Hellström
2023-11-01 17:23 ` Danilo Krummrich
2023-10-23 20:16 ` [PATCH drm-misc-next v7 5/7] drm/gpuvm: track/lock/validate external/evicted objects Danilo Krummrich
2023-10-31 11:34 ` Thomas Hellström
2023-10-31 16:41 ` Danilo Krummrich
2023-10-31 16:52 ` Thomas Hellström
2023-10-23 20:16 ` [PATCH drm-misc-next v7 6/7] drm/nouveau: make use of the GPUVM's shared dma-resv Danilo Krummrich
2023-10-23 20:16 ` [PATCH drm-misc-next v7 7/7] drm/nouveau: use GPUVM common infrastructure Danilo Krummrich
2023-10-31 12:38 ` [PATCH drm-misc-next v7 0/7] [RFC] DRM GPUVM features Boris Brezillon
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=ab8f30452540171447118d64931e66da96b6e85e.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=christian.koenig@amd.com \
--cc=dakr@redhat.com \
--cc=daniel@ffwll.ch \
--cc=donald.robson@imgtec.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=faith@gfxstrand.net \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.brost@intel.com \
--cc=nouveau@lists.freedesktop.org \
--cc=sarah.walker@imgtec.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