[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

[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

>> 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).


More information about the mesa-dev mailing list