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

[Rob Clark]

On Wed, Mar 23, 2016 at 8: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?

oh, I meant to send out an email about that but forgot..

but yeah, I think gbm should be able to do everything we need, so
seems pretty sensible.  Plus a way to handle intel/i965 and other
non-mesa drivers.  So we could basically replace all of drm_gralloc
with one smaller thing[*]..

[*] the caveat there is vmwgfx stuff which seems to want to do blits..
although I'm not entirely sure why or if that is even still requires
w/ newer vmware players.  But if vmwgfx still really needs the blit
path, I guess they could still keep using gralloc_drm instead of
switching to gralloc_gbm ;-)

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

Yeah, I think that shouldn't be a problem.. in the end, no matter how
many __DRIscreen's we should end up w/ a single (ref-cnt'd)
pipe_screen per process, so it should all just work out

BR,
-R