[Mesa-dev] [PATCH 00/10] egl/android: Improve the Android EGL backend

[Tomasz Figa]

On Tue, Jul 19, 2016 at 12:35 PM, Rob Herring <robh at kernel.org> wrote:
> On Fri, Jul 15, 2016 at 2:53 AM, Tomasz Figa <tfiga at chromium.org> wrote:
>> Hi,
>>
>> This series is a collection of various fixes and extensions we came up
>> with during our attempt to use Mesa for Android.
>>
>> Fixes included in this series:
>>  - added mandatory EGL_MAX_PBUFFER_WIDTH and _HEIGHT attributes to EGL
>>    configs,
>>  - fixed multiple issues with handling pbuffers in the backend,
>>  - found and fixed a DRI image leak,
>>  - made the implementation of DRI image loader .getBuffers callback
>>    conform better to the extension semantics.
>>
>> New features added by this series:
>>  - possibility to build the Android EGL platform without drm_gralloc
>>    headers,
>>  - support for creating EGL images from Android native buffers with
>>    YV12 pixel format (prime-only),
>>  - fallback to kms_swrast driver when no hardware driver can be loaded
>>    but there is still some usable DRI node present in the system.
>>  - more logging in case of errors to help diagnosing problems.
>>
>> Testing was done using classic i965 (gen 8) and gallium softpipe drivers
>> on an internal build of Android, based on gralloc backed by a DRM render
>> node and sharing buffers by PRIME FDs.
>
> I've tested out patches 1-6 with virgl and I don't get anything
> displayed. I get this message:
>
> EGL-DRI2: Front buffer is not supported for window surfaces
>
> That's as far as I investigated. I'll look into it some more tomorrow.

Thanks a lot for testing!

It looks like somehow your driver (or gallium) is triggering a call to
DRI image loader getBuffers() callback with front buffer bit set in
the image mask, but window surfaces on Android provide only back
buffers.

My understanding of the semantics was that the callback should deny
such requests, so that's how I implemented it. However it isn't really
well documented, so potentially it should only provide buffers that
are available and ignore the rest without bailing out. Could someone
more familiar with this extension comment on this?

>
> Patches 7-10 wouldn't apply. Do you have a git tree with the series?

Hmm, I rebased them on Mesa master just before sending. Let me try to
create a sandbox branch in our chromium tree.

Best regards,
Tomasz