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

[Rob Clark]

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?

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