Hi Emil,
On Thu, Jul 14, 2016 at 1:28 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 13 July 2016 at 04:29, Nicolas Boichat <drink...@chromium.org> wrote:
>> From: Tomasz Figa <tf...@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-sta...@lists.freedesktop.org>
>
>> Signed-off-by: Tomasz Figa <tf...@chromium.org>
>> Signed-off-by: Nicolas Boichat <drink...@chromium.org>
> For this and the "Remove unused variables" patch
> Reviewed-by: Emil Velikov <emil.veli...@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.
>
> 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.
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.
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).
>
> 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?
Best regards,
Tomasz
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
