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

[Rob Clark]

On Mon, Mar 28, 2016 at 12:29 PM, Rob Herring <robh at kernel.org> wrote:
> On Fri, Mar 25, 2016 at 8: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 think this can be implemented on top within gralloc as it is today
> with drm_gralloc.
>
> However, I found a bigger mismatch is there are no explicit map/unmap
> calls in GBM. A writeable buffer will be a dumb buffer and is
> implicitly mapped. Maybe that is enough in reality?
>

I think originally this was probably just used for uploading mouse
cursor, or something along those lines, rather than any serious use of
sw rendering.  But if android needs to mix hw and sw access to the
buffer, I think we do need something that maps to transfer_map/unmap,
so gl driver can (if needed) flush pending rendering and sync.

Not sure how others feel, but I wouldn't be opposed to extending gbm..
anything that can sit on top of transfer_map/unmap should coexist well
with a gpu driver.

BR,
-R