[Mesa-dev] Android DRM/Mesa porting (Was: need-help: how to change to newest mesa in android-x86?)

[Chih-Wei Huang]

(Rename the subject to address the topic properly)

First of all, I'm glad to invite more experts to
join the devel group, including
Rob Herring (kernel developer),
Emil Velikov (Mesa maintainer),
Rob Clark (Mesa developer),
and Sean Paul (main drm_hwcomposer author)
I also recall we have Chia-I Wu (olv),
the original drm_gralloc author in the list.

Thanks to Sean who just opened the latest
drm_hwcomposer to public:
https://chromium.googlesource.com/chromiumos/drm_hwcomposer

Contributing instructions:
https://sites.google.com/a/chromium.org/dev/contributing-to-drm_hwcomposer

Quoted from Rob Herring's email:
" ... my goal here is to try to unify Android DRM support
and the various implementations of gralloc and hwc.
It's necessary in order to get any Android specific features
in DRM upstream. I'm looking at other HALs too, and trying to unify
them and address any gaps in upstream kernel interfaces. I'm also
looking at device configuration and how to improve that. That seems to
be something that android-x86 gets right in supporting multiple
platforms in a single build with run-time configuration..."

Great!
Let's make it.

2016-01-16 5:30 GMT+08:00 Rob Herring <robherring2 at gmail.com>:
> On Fri, Jan 15, 2016 at 3:10 PM, Dave Airlie <airlied at gmail.com> wrote:
>>>
>>> well, nothing specific, but for example early on we had some confusion
>>> in drm_gralloc (when adding dmabuf fd support) about who close()d the
>>> fd's.  Resulting in same fd getting closed twice (although some
>>> completely unrelated file handle might have snuck into that slot
>>> between the two close()s).
>>>
>>> Or you could end up w/ the same sort of thing for gem handles (which
>>> are unique to the drm device fd, so if you open() the device multiple
>>> times..).  I did initially have some confusion about this, w/ multiple
>>> fd_bo's (or pipe_resource's) being created for a given gem handle, and
>>> first one that gets deleted takes away the backing store that both
>>> userspace references where using.
>>>
>>> You might want to look at freedreno_drm_winsys.c and the crazy things
>>> it does..  I suspect virgl might need similar hacks.  That is really
>>> one part of two, that ensures that we share the same pipe_screen, and
>>> therefore (from libdrm) fd_device, for a given drm device fd.  The
>>> other part is that fd_device has hashtables to deal w/ double import
>>> of gem buffers.
>>
>> I think Rob Clark might be on the right track here.
>>
>> it sounds like the host is sending double deletes for some objects, which
>> sounds like a possible reference counting bug in the host.
>>
>> So possibly something drm_gralloc, but it could be a bug in mesa, though
>> I haven't triggered anything like this yet.
>
> Okay, I'll start digging there.
>
>>
>> I'd be more willing to look at this if/when there is an easy to
>> produce android-x86
>> image that I could just drop newer mesa/drm_gralloc into, I suppose I could look
>> at ARM images, but I'm not really setup for cross dev, and I've a few
>> other things to
>> be doing.
>
> I've got a minimal build that is recent mesa and 4.4 kernel (only a
> couple of patches on top of each) and runs in a VM (or arm64). It is
> as easy as it gets with Android and rebuilding the world, but that's
> not saying too much. Instructions are here[1].
>
> Rob
>
> [1] https://github.com/robherring/generic_device/wiki/Android-with-DRM-mesa-graphics



-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org