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

[Rob Clark]

On Tue, Mar 8, 2016 at 2:22 AM, Rob Herring <robh at kernel.org> wrote:
> 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?

Any of the gallium drivers should support XA[1]..  but not classic
(non-gallium) drivers, which really only matters for intel.  So
basically the intel backend in drm_gralloc would have to remain, but
the nouveau/radeon/vmwgfx ones could be dropped[2]

[1] maybe at one point I had to make some makefile changes or
something like that?  Not sure, it was a long time ago when I first
started using XA in xf86-video-freedreno.  But if that was the case it
pre-dated pipe_loader_create_screen().. at least from point of view of
what features XA needs from gallium pipe driver, it is very minimal

[2] there is still the unrelated issue of how to deal w/ drm drivers
which do not (yet?) support atomic..

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

Hmm.. not 100% sure..  it is no problem to import/export dma-buf
handles (xa_handle_type_fd) from an xa_surface.  I guess *somewhere*
you need to be able to go from a native_handle_t <-> fd (and then <->
xa_surface).  So I'm not sure if that decouples mesa EGL from
drm_gralloc..

BR,
-R

> Rob
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev