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

[Rob Herring]

On Sun, Mar 6, 2016 at 10:32 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Sun, Mar 6, 2016 at 9:29 PM, Chih-Wei Huang <cwhuang at android-x86.org> wrote:
>> 2016-03-05 3:53 GMT+08:00 Rob Clark <robdclark at gmail.com>:
>>> On Fri, Mar 4, 2016 at 2:43 PM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
>>>> On 03/04/2016 07:07 PM, Rob Clark 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..
>>>>>
>>>>> BR,
>>>>> -R
>>>>>
>>>> and it was created for a very similar purpose, except that we also
>>>> needed some
>>>> render functionality, enough to composite surfaces.
>>>
>>> right, and since we have the ability to import/export dmabuf handles,
>>> I think it is a superset of what is needed.  (gralloc is using blits
>>> instead of flips for vmwgfx, for reasons I don't fully understand..
>>> but XA can do these blits and more, so we are still good there)
>>
>> Hi Rob,
>> Thank you for raising the problem though
>> I don't fully understand the technical details.
>>
>> So you are planning to modify (or re-implement?)
>> gralloc_drm_pipe to use the APIs of XA state tracker.
>
> well, unless I can talk someone else into doing it before I find time ;-)
>
> But yeah, if no one else does it (or comes up with a better idea
> first), I will eventually do it.
>
> fwiw, the XA API is:
>
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/xa/xa_tracker.h
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/xa/xa_context.h
> (ignoring the composite bits which we shouldn't need)
>
> I think that should provide everything needed for gralloc, but with a
> stable API rather than using the gallium pipe screen/context APIs
> directly.

This seems reasonable from what I've looked at it. Does supporting XA
require any h/w specific bits for gallium drivers and the classic
drivers already support XA?

One of the problems I've been looking at is dma-buf fds are not
exposed by gralloc in any standard way although various
implementations happen to be aligned. So mesa EGL has a dependency on
drm_gralloc to retrieve the fd from native_handle_t. Would we be able
to remove that dependency and retrieve the dma-buf fds directly from
XA?

Rob