[Mesa-dev] [PATCH] gallium/dri: Add shared glapi to LIBADD on Android

Emil Velikov emil.l.velikov at gmail.com
Thu Jul 14 16:02:05 UTC 2016


On 14 July 2016 at 04:11, Tomasz Figa <tfiga at chromium.org> wrote:
> Hi Emil,
>
> On Thu, Jul 14, 2016 at 1:28 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 13 July 2016 at 04:29, Nicolas Boichat <drinkcat at chromium.org> wrote:
>>> From: Tomasz Figa <tfiga at chromium.org>
>>>
>>> An earlier patch fixed the problem for classic drivers, however Gallium
>>> was still left broken. This patch applies the same workaround to
>>> Gallium, when compiled for Android. Following is a quote from the
>>> original patch:
>>>
>>> 0cbc90c57cfc mesa: dri: Add shared glapi to LIBADD on Android
>>>
>>> /system/vendor/lib/dri/*_dri.so actually depend on libglapi: without
>>> this, loading the so file fails with:
>>> cannot locate symbol "__emutls_v._glapi_tls_Context"
>>>
>>> On non-Android (non-bionic) platform, EGL uses the following
>>> workflow, which works fine:
>>>   dlopen("libglapi.so", RTLD_LAZY | RTLD_GLOBAL);
>>>   dlopen("dri/<driver>_dri.so", RTLD_NOW | RTLD_GLOBAL);
>>>
>>> However, bionic does not respect the RTLD_GLOBAL flag, and the dri
>>> library cannot find symbols in libglapi.so, so we need to link
>>> to libglapi.so explicitly. Android.mk already does this.
>>>
>> I believe we want to have this along side the classic patch, thus
>> Cc: "12.0" <mesa-stable at lists.freedesktop.org>
>>
>>> Signed-off-by: Tomasz Figa <tfiga at chromium.org>
>>> Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
>> For this and the "Remove unused variables" patch
>> Reviewed-by: Emil Velikov <emil.velikov at collabora.com>
>>
>> Out of curiosity: which driver was this tested with/against ?
>
> softpipe with kms_swrast target. I have a patch to add a fallback to
> it to Android EGL platform.
>
Ack, makes sense.

>>
>> Humble suggestion: if you re-spin the third_party/mesa, arc branch(es)
>> against 12.0 you'll see that many of your local patches are
>> merged/superseded. From a brief look most/all of the remaining are
>> also suitable for upstream, albeit they might need a bit of polish.
>
> I'm working on this (together with the getBuffers return value check
> for i915 you requested). :) Just my time budget has been a little
> tight lately.
>
> We try to keep our stuff rebased on reasonably current Mesa master,
> making sure that there are no significant dEQP regressions. You can
> find our last rebase to 12.1.0-devel here
> https://chromium-review.googlesource.com/#/c/358315/ , but I'm working
> on polishing things up and sending to mailing lists.
>
Please feel free to send patches out asap, even if it's just one or two.

> Things are a bit tricky because the gralloc supported in upstream Mesa
> currently provides some custom APIs, such as
> gralloc_drm_get_gem_handle() or GRALLOC_MODULE_PERFORM_GET_DRM_FD.
> Ours doesn't have any of this custom stuff and supports only sharing
> buffers by PRIME. It also doesn't share the DRI file descriptor with
> the client, because we found this was not behaving correctly on i965
> (at least - we don't use other drivers) with gralloc stepping over
> Mesa in certain conditions. To sum up, with our gralloc we don't
> include gralloc_drm*.h from Mesa and need to enumerate and open
> respective render node from Android EGL platform backend.
>
IIRC Rob H, did some pretty good work making sure that both render and
card node paths work. If the gralloc implementation provides an fd,
then render/prime is used. That happens with gralloc_gbm [1] (which
requires drm_hwcomposer, aka atomic modeset) which itself works with
gallium drivers only atm. Should be doable for i965 and/or other
classic DRI modules.

With that in mind, one could just add (even in mesa?) some temporary
redefintions and move people closer to using gralloc_gbm and upstream
mesa.

[1] https://github.com/robherring/gbm_gralloc

> Also Android requires the drivers to support xBGR8888 visuals, while
> last attempt to enable them in gallium broke some X11 apps. Need to
> figure out how to add it in such way that those apps are unaffected
> (even if broken by design because of expecting certain channel order
> without requesting it).
>
Iirc adding something like __DRIfooLoaderExtension::getCapabilities
(alike the __DRIimageExtension::getCapabilities) should get things
going.

>>
>> Let us know how we can help out with those and/or the .pc business
>> suggested earlier.
>
> I guess it would be useful if we could chat on IRC, but I suppose time
> zone difference could make this a bit difficult. Could you let me know
> your typical online hours?
>
I'm in #dri-devel almost all the time, although I keep an eye open in
the 9am-10pm range (GMT/UK time).

Thanks
Emil


More information about the mesa-dev mailing list