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 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 <he...@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 <r...@kernel.org> wrote: >>>> >>>> On Sat, Mar 9, 2019 at 6:21 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 >>>>> >>>>> 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 <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> >>>>> Cc: Dave Airlie <airl...@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> >>>>> Reviewed-by: Eric Anholt <e...@anholt.net> >>>>> Reviewed-by: Rob Herring <r...@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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
