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

[Rob Clark]

On Tue, Mar 29, 2016 at 10:30 AM, Rob Herring <robh at kernel.org> wrote:
> On Tue, Mar 29, 2016 at 8:43 AM, Rob Clark <robdclark at gmail.com> wrote:
>> 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.
>
> Looks like it was tried already[1]. Interestingly, the gralloc lock
> interface already does some of what is discussed being needed
> (specifying the region).

yeah, as does pipe->transfer_map/unmap (which is ofc supported by
vmwgfx gallium driver).

So I think the issue is to just make the API look more like
transfer_map/unmap (ie. specify a region.. and probably usage flags..
I don't think it would be applicable for cube/array/3d textures so
'level' probably not required.), rather than blind 'give me a void *
for the whole buffer' sort of thing..

BR,
-R

> Rob
>
> [1] https://lists.freedesktop.org/archives/mesa-dev/2014-April/058484.html
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev