dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: dri-devel@lists.freedesktop.org
Cc: "Marek Vasut" <marex@denx.de>,
	lima@lists.freedesktop.org,
	"Andreas Baierl" <ichgeh@imkreisrum.de>,
	"Maxime Ripard" <maxime.ripard@bootlin.com>,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"David Airlie" <airlied@linux.ie>, "Qiang Yu" <yuq825@gmail.com>,
	"Simon Shields" <simon@lineageos.org>,
	"Vasily Khoruzhick" <anarsoul@gmail.com>,
	"Sean Paul" <sean@poorly.run>,
	"Erico Nunes" <nunes.erico@gmail.com>
Subject: Re: [PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs
Date: Wed, 06 Mar 2019 09:37:02 -0800	[thread overview]
Message-ID: <87bm2nkipt.fsf@anholt.net> (raw)
In-Reply-To: <20190306152339.5340-1-yuq825@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2203 bytes --]

Qiang Yu <yuq825@gmail.com> writes:

> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
>   OpenGL vertex shader processing and PP is for fragment shader
>   processing. Each processor has its own MMU so prcessors work in
>   virtual address space.
> - There's only one GP but multiple PP (max 4 for mali 400 and 8
>   for mali 450) in the same mali 4xx GPU. All PPs are grouped
>   togather to handle a single fragment shader task divided by
>   FB output tiled pixels. Mali 400 user space driver is
>   responsible for assign target tiled pixels to each PP, but mali
>   450 has a HW module called DLBU to dynamically balance each
>   PP's load.
> - User space driver allocate buffer object and map into GPU
>   virtual address space, upload command stream and draw data with
>   CPU mmap of the buffer object, then submit task to GP/PP with
>   a register frame indicating where is the command stream and misc
>   settings.
> - There's no command stream validation/relocation due to each user
>   process has its own GPU virtual address space. GP/PP's MMU switch
>   virtual address space before running two tasks from different
>   user process. Error or evil user space code just get MMU fault
>   or GP/PP error IRQ, then the HW/SW will be recovered.
> - Use GEM+shmem for MM. Currently just alloc and pin memory when
>   gem object creation. GPU vm map of the buffer is also done in
>   the alloc stage in kernel space. We may delay the memory
>   allocation and real GPU vm map to command submission stage in the
>   furture as improvement.
> - Use drm_sched for GPU task schedule. Each OpenGL context should
>   have a lima context object in the kernel to distinguish tasks
>   from different user. drm_sched gets task from each lima context
>   in a fair way.
>
> mesa driver can be found here before upstreamed:
> https://gitlab.freedesktop.org/lima/mesa
>
> v7:
> - remove lima_fence_ops with default value
> - move fence slab create to device probe
> - check pad ioctl args to be zero
> - add comments for user/kernel interface

Thanks for adding the comments!  That helps a lot.  I feel pretty good
about the ABI at this point.

Reviewed-by: Eric Anholt <eric@anholt.net>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-03-06 17:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-06 15:23 [PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs Qiang Yu
2019-03-06 17:37 ` Eric Anholt [this message]
2019-03-06 23:45 ` Rob Herring
2019-03-07  0:08   ` Dave Airlie
2019-03-07  1:43     ` Qiang Yu
2019-03-07  1:11   ` Eric Anholt
2019-03-07  2:20     ` Qiang Yu
2019-03-07  0:15 ` Dave Airlie
2019-03-07  1:52   ` Qiang Yu

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=87bm2nkipt.fsf@anholt.net \
    --to=eric@anholt.net \
    --cc=airlied@linux.ie \
    --cc=anarsoul@gmail.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --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=sam@ravnborg.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).