Hi, So what's the status of it?
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
