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

[Stéphane Marchesin]

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.

It becomes even worse when your have multiple instances of video or display
units in your SOC and the flag just says "video" or "display". But that
doesn't work in gralloc either so :)

Stéphane

>
> BR,
> -R
>
> >>
> >> it certainly would be convenient to not have to care about both gbm
> >> and gralloc from driver standpoint.
> >
> > Absolutely.
> >
> > Stéphane
> >
> >>
> >> BR,
> >> -R
> >>
> >>
> >> > Stéphane
> >> >
> >> >>
> >> >> I spent a bit of time and dug into GBM some more. It appears to me
> >> >> that GBM would have the same screen sharing issue. AFAICT, it
depends
> >> >> on whether multiple __DRIscreen's are okay as long as the
pipe_screen
> >> >> is shared?
> >> >>
> >> >> Rob
> >> _______________________________________________
> >> mesa-dev mailing list
> >> mesa-dev at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160326/e29c4abb/attachment-0001.html>