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

[Rob Clark]

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?

BR,
-R

> 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