On 14 July 2016 at 04:11, Tomasz Figa <tf...@chromium.org> wrote: > 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. > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev