[PATCH v8] drm/lima: driver for ARM Mali4xx GPUs

Wed Mar 27 13:53:50 UTC 2019

Hi Neil,

On Wed, Mar 27, 2019 at 10:15:48AM +0100, Neil Armstrong wrote:
> Hi,
> 
> On 26/03/2019 21:40, Vasily Khoruzhick wrote:
> > Hi,
> > 
> > So what's the status of it?
> 
> We are waiting on ARM to give a feedback on the ARM GPU tile modifier,
> see https://patchwork.freedesktop.org/patch/292187/?series=57996&rev=1

Certainly that series is still waiting for Arm to come up with a patch
(FWIW it is not forgotten, and several of us are still pushing it
internally).

However, is having the tiled format definition a requirement for
merging the rest of the driver? Isn't it more of an optimisation?

I would imagine (I don't know) that the GPU must be able to write out
linear, otherwise I don't think its framebuffers could be scanned out
by any display HW.

Thanks,
-Brian

> 
> Neil
> 
> > 
> > Has it been merged? I don't see it in drm-misc-next.
> > 
> > Regards,
> > Vasily
> > 
> > On Tue, Mar 12, 2019 at 1:12 AM Heiko Stuebner <heiko at sntech.de> wrote:
> >>
> >> Hi,
> >>
> >> Am Dienstag, 12. März 2019, 02:54:57 CET schrieb Qiang Yu:
> >>> On Mon, Mar 11, 2019 at 11:37 PM Rob Herring <robh at kernel.org> wrote:
> >>>>
> >>>> On Sat, Mar 9, 2019 at 6:21 AM Qiang Yu <yuq825 at gmail.com> wrote:
> >>>>>
> >>>>> - 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
> >>>>>
> >>>>> v8:
> >>>>> - add comments for in_sync
> >>>>> - fix ctx free miss mutex unlock
> >>>>>
> >>>>> 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
> >>>>>
> >>>>> v6:
> >>>>> - fix comments by checkpatch.pl
> >>>>>
> >>>>> v5:
> >>>>> - export gp/pp version to userspace
> >>>>> - rebase on drm-misc-next
> >>>>>
> >>>>> v4:
> >>>>> - use get param interface to get info
> >>>>> - separate context create/free ioctl
> >>>>> - remove unused max sched task param
> >>>>> - update copyright time
> >>>>> - use xarray instead of idr
> >>>>> - stop using drmP.h
> >>>>>
> >>>>> v3:
> >>>>> - fix comments from kbuild robot
> >>>>> - restrict supported arch to tested ones
> >>>>>
> >>>>> v2:
> >>>>> - fix syscall argument check
> >>>>> - fix job finish fence leak since kernel 5.0
> >>>>> - use drm syncobj to replace native fence
> >>>>> - move buffer object GPU va map into kernel
> >>>>> - reserve syscall argument space for future info
> >>>>> - remove kernel gem modifier
> >>>>> - switch TTM back to GEM+shmem MM
> >>>>> - use time based io poll
> >>>>> - use whole register name
> >>>>> - adopt gem reservation obj integration
> >>>>> - use drm_timeout_abs_to_jiffies
> >>>>>
> >>>>> Cc: Eric Anholt <eric at anholt.net>
> >>>>> Cc: Rob Herring <robh at kernel.org>
> >>>>> Cc: Christian König <ckoenig.leichtzumerken at gmail.com>
> >>>>> Cc: Daniel Vetter <daniel at ffwll.ch>
> >>>>> Cc: Alex Deucher <alexdeucher at gmail.com>
> >>>>> Cc: Sam Ravnborg <sam at ravnborg.org>
> >>>>> Cc: Rob Clark <robdclark at gmail.com>
> >>>>> Cc: Dave Airlie <airlied at gmail.com>
> >>>>> Signed-off-by: Andreas Baierl <ichgeh at imkreisrum.de>
> >>>>> Signed-off-by: Erico Nunes <nunes.erico at gmail.com>
> >>>>> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> >>>>> Signed-off-by: Marek Vasut <marex at denx.de>
> >>>>> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
> >>>>> Signed-off-by: Simon Shields <simon at lineageos.org>
> >>>>> Signed-off-by: Vasily Khoruzhick <anarsoul at gmail.com>
> >>>>> Signed-off-by: Qiang Yu <yuq825 at gmail.com>
> >>>>> Reviewed-by: Eric Anholt <eric at anholt.net>
> >>>>> Reviewed-by: Rob Herring <robh at kerrnel.org>
> >>>>> ---
> >>>>
> >>>> [...]
> >>>
> >>> I thought get your RB last time, should I remove it?
> >>
> >> I read Rob's comment as "if you need to resent for any other reason
> >> then you could modify for that patch, but no need to resend everything
> >> just for this", so a RB can probably stay as it is.
> >>
> >>
> >> Heiko
> >>
> >>>> Not to make you keep shooting for a moving target, Eric just posted a
> >>>> patch[1] a few days ago that can replace these 2 functions. Would be
> >>>> good to use if you respin, but otherwise can be a follow-on patch.
> >>>
> >>> Thanks for the remind.
> >>>
> >>> Regards,
> >>> Qiang
> >>
> >>
> >>
> >>
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel