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

[Rob Clark]

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...

it certainly would be convenient to not have to care about both gbm
and gralloc from driver standpoint.

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