From: Alex Deucher via dri-devel <dri-devel@lists.freedesktop.org>
To: Rob Herring <robh@kernel.org>
Cc: Marek Vasut <marex@denx.de>, Simon Shields <simon@lineageos.org>,
lima@lists.freedesktop.org,
Neil Armstrong <narmstrong@baylibre.com>,
Maxime Ripard <maxime.ripard@bootlin.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
Vasily Khoruzhick <anarsoul@gmail.com>,
David Airlie <airlied@linux.ie>, Qiang Yu <yuq825@gmail.com>,
Sean Paul <sean@poorly.run>,
Andreas Baierl <ichgeh@imkreisrum.de>,
Erico Nunes <nunes.erico@gmail.com>
Subject: Re: [PATCH 2/2] drm/lima: driver for ARM Mali4xx GPUs
Date: Wed, 13 Feb 2019 21:52:39 -0500 [thread overview]
Message-ID: <CADnq5_OSjAqiDXXFfPE9sAQ5vsE4oBj-Y0tFO=jFwA9zpOE_Qw@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqJE120YMHp=yTCqOFW3CQXDMS4f9_QHi9E0SKC5t0NZOQ@mail.gmail.com>
I typed this up yesterday, but it looks like I never hit send.
On Tue, Feb 12, 2019 at 3:05 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Feb 12, 2019 at 10:24 AM Alex Deucher <alexdeucher@gmail.com> wrote:
> >
> > On Tue, Feb 12, 2019 at 10:53 AM Rob Herring via dri-devel
> > <dri-devel@lists.freedesktop.org> wrote:
> > >
> > > On Wed, Feb 6, 2019 at 7:16 AM Qiang Yu <yuq825@gmail.com> wrote:
> > > >
> > > > From: Lima Project Developers <lima@lists.freedesktop.org>
>
> [...]
>
> > > > +static int lima_ioctl_gem_va(struct drm_device *dev, void *data, struct drm_file *file)
> > > > +{
> > > > + struct drm_lima_gem_va *args = data;
> > > > +
> > > > + switch (args->op) {
> > > > + case LIMA_VA_OP_MAP:
> > > > + return lima_gem_va_map(file, args->handle, args->flags, args->va);
> > > > + case LIMA_VA_OP_UNMAP:
> > > > + return lima_gem_va_unmap(file, args->handle, args->va);
> > >
> > > These are mapping to GPU VA. Why not do that on GEM object creation or
> > > import or when the objects are submitted with cmd queue as other
> > > drivers do?
> > >
> > > To put it another way, These ioctls look different than what other
> > > drivers do. Why do you need to do things differently? My understanding
> > > is best practice is to map and return the GPU offset when the GEM
> > > object is created. This is what v3d does. I think Intel is moving to
> > > that. And panfrost will do that.
> >
> > I think it would be a good idea to look at the amdgpu driver. This
> > driver is heavily modeled after it. Basically the GEM VA ioctl allows
> > userspace to manage per process (per fd really) virtual addresses.
>
> Why do you want userspace to manage assigning VAs versus the kernel to
> do so? Exposing that detail to userspace means the driver must support
> a per process address space. Letting the kernel assign addresses means
> it can either be a single address space or be a per process address
> space. It seems to me more flexible to allow the kernel driver to
> evolve without that ABI.
Having it in userspace provides a lot more flexibility and makes it
easier to support things like unified address space between CPU and
GPU. I guess it depends on the hw as to what is the right choice.
>
> With any new driver in the kernel, the question is always which
> existing one is the best model to follow. I don't think Intel, AMD or
> Nouveau are good examples to follow because they have a lot of history
> and legacy, are both GPU and DC, and have separate graphics memory
> (except Intel I guess). The GPUs in ARM land have none of those
> really. Looking thru freedreno, etnaviv, and v3d mostly, I see they
> all have similar user ABIs. But they are all different based on what
> driver they copied and how they've evolved. I know it's a big can of
> worms, but it would be nice to have some alignment of ABIs. I know the
> reasons why there isn't, but it's frustrating that 11 out of 60K IGT
> tests will run. I don't think a common ABI matters much for the big 3,
> but in the ARM zoo I think it does. At least if the interfaces are
> kept similar, then having common code shared among the embedded GPUs
> would be easier and writing some IGT shim for each driver would be
> easier.
It also depends on what you are familiar with. Qiang is familiar with
amdgpu so it makes sense to use that as a model for his own projects.
I don't know that similarity between drivers for hw that is mostly
part of ARM SoCs is any more important than the applicability to the
hw or what the maintainer likes. I mean you can use amdgpu or nouveau
on ARM too.
Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-02-14 2:52 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-06 13:14 [PATCH 0/2] Lima DRM driver Qiang Yu
2019-02-06 13:14 ` [PATCH 1/2] drm/fourcc: add ARM tiled format modifier Qiang Yu
2019-02-14 15:26 ` Brian Starkey
2019-02-14 15:34 ` Daniel Vetter
2019-02-15 1:48 ` Qiang Yu via dri-devel
2019-02-15 11:30 ` Brian Starkey
2019-02-06 13:14 ` [PATCH 2/2] drm/lima: driver for ARM Mali4xx GPUs Qiang Yu
2019-02-06 19:17 ` Eric Anholt
2019-02-07 8:27 ` Qiang Yu
2019-02-07 19:38 ` Eric Anholt
2019-02-12 15:46 ` Rob Herring via dri-devel
2019-02-12 16:23 ` Alex Deucher via dri-devel
2019-02-12 20:04 ` Rob Herring via dri-devel
2019-02-13 1:13 ` Qiang Yu via dri-devel
2019-02-14 2:52 ` Alex Deucher via dri-devel [this message]
2019-02-14 9:12 ` Christian König via dri-devel
2019-02-14 10:15 ` Daniel Vetter
2019-03-14 20:44 ` Dave Airlie
2019-03-14 21:44 ` Rob Herring
2019-03-14 22:28 ` Eric Anholt
2019-03-15 8:06 ` Koenig, Christian
2019-03-15 16:05 ` Eric Anholt
2019-03-15 16:19 ` Koenig, Christian
2019-02-13 0:56 ` Qiang Yu via dri-devel
2019-02-13 1:46 ` Rob Herring via dri-devel
2019-02-07 9:09 ` [PATCH 0/2] Lima DRM driver Daniel Vetter
2019-02-07 9:39 ` Christian König
2019-02-07 15:33 ` Qiang Yu
2019-02-07 19:14 ` Koenig, Christian
2019-02-07 15:21 ` Qiang Yu
2019-02-07 15:44 ` Alyssa Rosenzweig
2019-02-07 15:51 ` Daniel Vetter
2019-02-11 18:11 ` Rob Herring
2019-02-13 1:00 ` Eric Anholt
2019-02-13 1:44 ` Rob Herring via dri-devel
2019-02-13 7:59 ` Daniel Vetter
2019-02-13 8:35 ` Christian König via dri-devel
2019-02-13 9:38 ` Daniel Vetter
2019-02-13 10:09 ` Christian König via dri-devel
2019-02-26 15:58 ` Daniel Vetter
2019-02-26 16:23 ` Christian König
2019-02-14 21:15 ` Noralf Trønnes
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='CADnq5_OSjAqiDXXFfPE9sAQ5vsE4oBj-Y0tFO=jFwA9zpOE_Qw@mail.gmail.com' \
--to=dri-devel@lists.freedesktop.org \
--cc=airlied@linux.ie \
--cc=alexdeucher@gmail.com \
--cc=anarsoul@gmail.com \
--cc=ichgeh@imkreisrum.de \
--cc=lima@lists.freedesktop.org \
--cc=marex@denx.de \
--cc=maxime.ripard@bootlin.com \
--cc=narmstrong@baylibre.com \
--cc=nunes.erico@gmail.com \
--cc=robh@kernel.org \
--cc=sean@poorly.run \
--cc=simon@lineageos.org \
--cc=yuq825@gmail.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;
as well as URLs for NNTP newsgroup(s).