[Mesa-dev] [android-x86-devel] Re: gralloc_drm_pipe

Tue Mar 29 15:44:43 UTC 2016

On Tue, Mar 29, 2016 at 10:00:00AM -0400, Rob Clark wrote:
> On Tue, Mar 29, 2016 at 4:41 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> > On Sat, Mar 26, 2016 at 07:44:58PM -0400, Rob Clark wrote:
> >> On Sat, Mar 26, 2016 at 7:09 PM, Stéphane Marchesin
> >> <stephane.marchesin at gmail.com> wrote:
> >> >
> >> > On Mar 26, 2016 16:05, "Rob Clark" <robdclark at gmail.com> wrote:
> >> >>
> >> >> On Sat, Mar 26, 2016 at 6:42 PM, Stéphane Marchesin
> >> >> <stephane.marchesin at gmail.com> wrote:
> >> >> >
> >> >> > On Mar 26, 2016 3:09 PM, "Rob Clark" <robdclark at gmail.com> wrote:
> >> >> >>
> >> >> >> On Fri, Mar 25, 2016 at 9:38 PM, Stéphane Marchesin
> >> >> >> <marcheu at google.com>
> >> >> >> wrote:
> >> >> >> > On Wed, Mar 23, 2016 at 5:22 PM, Rob Herring <robh at kernel.org> wrote:
> >> >> >> >> On Fri, Mar 4, 2016 at 12:07 PM, Rob Clark <robdclark at gmail.com>
> >> >> >> >> wrote:
> >> >> >> >>> On Fri, Mar 4, 2016 at 12:59 PM, Rob Clark <robdclark at gmail.com>
> >> >> >> >>> wrote:
> >> >> >> >>>> So, I've been advocating that for android, gallium drivers use
> >> >> >> >>>> gralloc_drm_pipe, since with android it seems like you end up with
> >> >> >> >>>> both gralloc and libGL in the same process, and having both share
> >> >> >> >>>> the
> >> >> >> >>>> same pipe_screen avoids lots of headaches with multiple gem
> >> >> >> >>>> handles
> >> >> >> >>>> pointing to same underlying buffer.
> >> >> >> >>>>
> >> >> >> >>>> But the awkward thing is that gralloc_drm_pipe is using gallium
> >> >> >> >>>> APIs
> >> >> >> >>>> that aren't particularly intended to be used out-of-tree.  Ie. not
> >> >> >> >>>> really stable APIs.  At the time, the thing that made sense to me
> >> >> >> >>>> was
> >> >> >> >>>> to pull drm_gralloc into mesa.  But at the time, there were no
> >> >> >> >>>> non-mesa users of drm_gralloc, which isn't really true anymore.
> >> >> >> >>>>
> >> >> >> >>>> Maybe what makes more sense now is to implement a gralloc state
> >> >> >> >>>> tracker, which exposes a stable API for drm_gralloc?  It would
> >> >> >> >>>> mostly
> >> >> >> >>>> be a shim to expose gallium import/export/transfer APIs in a
> >> >> >> >>>> stable
> >> >> >> >>>> way, but would also be where the code that figures out which
> >> >> >> >>>> driver
> >> >> >> >>>> to
> >> >> >> >>>> use to create/get the pipe_screen.
> >> >> >> >>>
> >> >> >> >>> and actually, we might just be able to use XA state tracker for
> >> >> >> >>> this..
> >> >> >> >>> I think it exposes all the necessary import/export/etc stuff that
> >> >> >> >>> gralloc would need..
> >> >> >> >>
> >> >> >> >> Rob and I discussed this a bit more F2F recently. An alternative we
> >> >> >> >> discussed would be using GBM instead. GBM seems more inline with
> >> >> >> >> gralloc needs. This would also have the advantage of working with
> >> >> >> >> minigbm as well for non-mesa cases. Any thoughts on GBM vs. XA?
> >> >> >> >
> >> >> >> > gbm as it is misses some bits, for example lock/unlock, and more fine
> >> >> >> > grained usage flags.
> >> >> >> >
> >> >> >> > I'm also planning to look into something similar with minigbm, i.e.
> >> >> >> > have one backend and expose a minigbm and a gralloc frontend on top.
> >> >> >> > But I'm not sure if it's possible/sensible yet.
> >> >> >>
> >> >> >> I haven't thought about the details, but in principle I wouldn't be
> >> >> >> opposed to extending gbm to add whatever is needed...
> >> >> >
> >> >> > Yeah that's what I want to do: extend the api and the drivers as needed
> >> >> > (I
> >> >> > might just expose a new internal api but no new gbm api...). But one
> >> >> > place
> >> >> > where things are fundamentally different is that gbm in mesa only knows
> >> >> > about 3d while gralloc knows about system wide stuff like video etc.
> >> >> >
> >> >>
> >> >> hmm, presumably that problem goes away once fence + syncpt stuff is
> >> >> wired up through all the drivers?
> >> >
> >> > Synchronization is just one piece. Your also have to consider things like
> >> > alignment and format restrictions for video decode for example. These can be
> >> > different from 3d so you need some knowledge of the video engine for
> >> > example. Ditto with everything else.
> >>
> >> hmm, admittedly I'm used to think of gpu as the most restrictive thing..
> >>
> >> But maybe to start with we don't have to solve all the world's
> >> problems.. maybe it is good enough to do a reference gbm_gralloc which
> >> works in the common cases.. SoC vendors can still replace it with
> >> their own thing when the generic one doesn't fit their needs.  Going
> >> from "everyone has their own implementation" to "some have their own
> >> implementation" seems like forward progress.
> >>
> >> At least then we can get to something that works for all the mesa
> >> drivers and at least a reasonable subset of everyone else..
> >
> > At least with video I thought the Grand Android Plan was to switch over to
> > v4l? Maybe we just need to add/query some v4l apis to figure out what's
> > needed for a basic gralloc that works everywhere. There's still the
> > question of where to allocate stuff, but maybe a simple heuristics like
> > assuming that display > v4l > gpu wrt placement constraints (e.g.
> > allocating from cma or not) should be good enough? Maybe with an optional
> > fallback to some ION heap for some shared buffers, there's a todo
> > somewhere about that.
> 
> fwiw, I think on msm actually v4l is the most restrictive and display
> is the least restrictive ;-)
> 
> At least none need contig memory (well, not sure about secure
> playback, but for upstream+AOSP I guess we can ignore that), so it is
> mostly about pitch requirements for various formats.
> 
> I suppose we could chicken out and have a platform specific config
> file or quirks table?

staging/android/TODO already has an entry to add dt bindings so that ion
could expose a cma heap already used by a device for dma allocations. Only
bit we need on top would then to expose that in sysfs (link from the dev
to the ion heap should be doable), and then use that in gralloc to figure
out where to allocate a shared buffer. Pick the above heuristics as a
start, then walk sysfs upwards from all the device nodes (drm/v4l/...)
until you have an ion heap that works for all of them.

We might need to create a hirarchy of cma heaps on, also exposed in sysfs,
in case some devices have disjoint cma heaps somehow ...

Someone would need to prototype this to actually see how silly it is.
Bonus points: We could destage ion if that's done, since most of the other
issues around sync are now handled with the addition of the SYNC ioct to
dma-buf in 4.6.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch