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

[Daniel Vetter]

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.

Just throwing out my thoughts, I agree that starting out with a gralloc
that's good enough for display+gpu sounds like a solid plan.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch