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 <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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
