On Thu, Mar 7, 2019 at 9:11 AM Eric Anholt <e...@anholt.net> wrote: > > Rob Herring <r...@kernel.org> writes: > > > On Wed, Mar 6, 2019 at 9:24 AM Qiang Yu <yuq...@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 > >> > >> 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 <e...@anholt.net> > >> Cc: Rob Herring <r...@kernel.org> > >> Cc: Christian König <ckoenig.leichtzumer...@gmail.com> > >> Cc: Daniel Vetter <dan...@ffwll.ch> > >> Cc: Alex Deucher <alexdeuc...@gmail.com> > >> Cc: Sam Ravnborg <s...@ravnborg.org> > >> Cc: Rob Clark <robdcl...@gmail.com> > >> Signed-off-by: Andreas Baierl <ich...@imkreisrum.de> > >> Signed-off-by: Erico Nunes <nunes.er...@gmail.com> > >> Signed-off-by: Heiko Stuebner <he...@sntech.de> > >> Signed-off-by: Marek Vasut <ma...@denx.de> > >> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com> > >> Signed-off-by: Simon Shields <si...@lineageos.org> > >> Signed-off-by: Vasily Khoruzhick <anars...@gmail.com> > >> Signed-off-by: Qiang Yu <yuq...@gmail.com> > >> --- > >> drivers/gpu/drm/Kconfig | 2 + > >> drivers/gpu/drm/Makefile | 1 + > >> drivers/gpu/drm/lima/Kconfig | 10 + > >> drivers/gpu/drm/lima/Makefile | 21 ++ > >> drivers/gpu/drm/lima/lima_bcast.c | 47 +++ > >> drivers/gpu/drm/lima/lima_bcast.h | 14 + > >> drivers/gpu/drm/lima/lima_ctx.c | 97 ++++++ > >> drivers/gpu/drm/lima/lima_ctx.h | 30 ++ > >> drivers/gpu/drm/lima/lima_device.c | 385 +++++++++++++++++++++++ > >> drivers/gpu/drm/lima/lima_device.h | 131 ++++++++ > >> drivers/gpu/drm/lima/lima_dlbu.c | 58 ++++ > >> drivers/gpu/drm/lima/lima_dlbu.h | 18 ++ > >> drivers/gpu/drm/lima/lima_drv.c | 376 +++++++++++++++++++++++ > >> drivers/gpu/drm/lima/lima_drv.h | 45 +++ > >> drivers/gpu/drm/lima/lima_gem.c | 381 +++++++++++++++++++++++ > >> drivers/gpu/drm/lima/lima_gem.h | 25 ++ > >> drivers/gpu/drm/lima/lima_gem_prime.c | 47 +++ > >> drivers/gpu/drm/lima/lima_gem_prime.h | 13 + > >> drivers/gpu/drm/lima/lima_gp.c | 283 +++++++++++++++++ > >> drivers/gpu/drm/lima/lima_gp.h | 16 + > >> drivers/gpu/drm/lima/lima_l2_cache.c | 80 +++++ > >> drivers/gpu/drm/lima/lima_l2_cache.h | 14 + > >> drivers/gpu/drm/lima/lima_mmu.c | 142 +++++++++ > >> drivers/gpu/drm/lima/lima_mmu.h | 16 + > >> drivers/gpu/drm/lima/lima_object.c | 122 ++++++++ > >> drivers/gpu/drm/lima/lima_object.h | 36 +++ > >> drivers/gpu/drm/lima/lima_pmu.c | 60 ++++ > >> drivers/gpu/drm/lima/lima_pmu.h | 12 + > >> drivers/gpu/drm/lima/lima_pp.c | 427 ++++++++++++++++++++++++++ > >> drivers/gpu/drm/lima/lima_pp.h | 19 ++ > >> drivers/gpu/drm/lima/lima_regs.h | 298 ++++++++++++++++++ > >> drivers/gpu/drm/lima/lima_sched.c | 404 ++++++++++++++++++++++++ > >> drivers/gpu/drm/lima/lima_sched.h | 104 +++++++ > >> drivers/gpu/drm/lima/lima_vm.c | 282 +++++++++++++++++ > >> drivers/gpu/drm/lima/lima_vm.h | 62 ++++ > >> include/uapi/drm/lima_drm.h | 164 ++++++++++ > >> 36 files changed, 4242 insertions(+) > > > > Reviewed-by: Rob Herring <r...@kerrnel.org> > > > > I can apply this if you want, though I'm not completely sure whether > > folks want the mesa bits to go upstream first. > > They'd need to hide the Mesa usage of the ABI until the kernel merges > anyway, so it's enough that it's public in a way that targets Mesa.
I'd like to get this merged first if accepted instead of maintain a separate branch when mesa upstream process. mesa part could have a kernel driver when the upstream gets reviewed too. Regards, Qiang _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel