Uhm, dropped other recipients by mistake last time. As I said, it was too late hour to reply for me. :)
On Sun, May 29, 2016 at 2:09 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 27 May 2016 at 17:22, Tomasz Figa <tf...@chromium.org> wrote: >> On Sat, May 28, 2016 at 12:48 AM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> Hello gents, >>> >>> On 27 May 2016 at 12:33, Tomasz Figa <tf...@chromium.org> wrote: >>>> Hi, >>>> >>>> On Fri, May 27, 2016 at 7:36 PM, Nicolas Boichat <drink...@chromium.org> >>>> wrote: >>>>> Hi Emil, >>>>> >>>>> Took us some time to clean things up, but we got an ebuild and repo to >>>>> share with you. >>>>> >>>>> On Tue, May 24, 2016 at 10:52 PM, Emil Velikov <emil.l.veli...@gmail.com> >>>>> wrote: >>>>> [snip] >>>>>>> We also set PKGCONFIG="false", because, well, we do not have .pc files >>>>>>> for Android libs. We _could_ create them manually, though, >>>>>> Arr... it seems like there's more 'hacks' then expected. I would >>>>>> kindly urge that if you're using the autoconf build to use .pc files, >>>>>> please ? >>>>>> >>>>>> There's not need to manually create any of them - just throw the >>>>>> template and wire it up in the build system. >>>>> >>>>> Not quite sure how that'd work out, I guess I'll see ,-) >>>>> >>>> >>>> I'd also vote for using .pc files for the non-Android dependencies, >>>> but I'm not sure how we could use them for Android ones. Do you mean >>>> hacking up something like android_egl.pc that would include all the >>>> necessary Android libraries for the EGL platform module? >>>> >>> Ideally there'll be a separate .pc for each required library/module. >>> >>>> One more thing to note is that this series is an attempt to make it >>>> possible to build Mesa for Android externally, without the need to >>>> maintain a whole alternative set of makefiles or other redundant >>>> entities. So I think we shouldn't go to extremes and now the users of >>>> this create yet another type of such objects for Android side of >>> > things (.pc files), if it could just stay there in the source tree, >>>> unlikely to require changes in any near future. >>>> >>> /me scratches head and attempts to parse two consecutive 4 line sentences. >>> Can you please rephrase the above ? >> >> Can't even parse it myself now, I guess too late hour to write emails for me. >> >> I believe I meant that this series attempts to reduce the number of >> extra files needed to build Mesa for Android, so asking the user (the >> person building) to create more of them (pc for Android libs) would be >> IMHO a bit contradictory. >> > That's why I proposed to create them ;-) If anyone else wants to > rebuild mesa in a similar way they are bound to use AOSP {,based} > packages - libhardware... thus once things are in, there'll be no > overhead/drawback for anyone. > >>> >>>> One alternative for the two mentioned solutions would be just letting >>>> the user specify the list of Android libraries to include using >>>> environment variables, without involving pkgconfig into this at all. >>>> This way we would neither have to create .pc files for Android >>>> libraries nor hardcode specific library names into Makefile.am. >>>> >>> That's an option indeed. Sadly the the easiest way to butcher >>> things... as in one will get things right eventually, but the time >>> spent debugging/asking around will be far greater than hacking 2-3 .pc >>> files. >> >> Hmm, let me make sure that I have a correct understanding. >> >> So with the setup you're suggesting we would have pkgconfig modules >> for libhardware, libcutils and libsync. Then from Makefile.am we would >> dereference the respective _CFLAGS and _LIBS variables. > Yes. It would be really good if we can have that. > >> So, if I got >> this right, it would mean hardcoding indirectly the dependencies for >> certain Android libs in Makefile.am. How is this different from simply >> adding "-lhardware -lcutils -lsync" there? >> > As a counter argument why does anyone bothers with .pc (and equivalent > cmake) files ;-) > > Let me try to break down and answer your (personally or as a team) concerns: > - Who will create the said files ? > If you guys don't have time/interest I can do that ;-) > - Why bother since we can hardcode it in the ebuild. > Yes, but one might want to build it via another method - yocto, > buildroot, rpms (.spec files) ... Thus the said thing will have to be > copied everywhere and then kept in sync. > - It feels strange having .pc files in an AOSP build system. > Fully agree. Yet it's a very small price (both initial 'investment' > and maintenance) to pay for a cleaner solution and greater > portability. On a similar note some (sadly not many) upstream projects > keep the Android build upstream as a sign of good will towards > Android. > > I get the feeling that each of us, individually, could have written > the said .pc files in a fraction of the actual discussion. Yeah, writing is not the thing I was concerned about, but rather where to put them. But maybe we can indeed manage to include them in AOSP, to be honest I didn't even think about this. > >>>>> >>>>>>> So we replace them with LIBXYZ_[CFLAGS/LIBS], and configure is happy >>>>>>> with that. >>>>>>> >>>>>>> One thing that I wonder about is how we could specify >>>>>>> libEGL_la_LIBADD += -lhardware -lcutils -lsync >>>>>>> without hardcoding it in the Makefile.am. >>>>>>> >>>>>>> Any idea how we could do that? Or do you think it's ok to hardcode the >>>>>>> libs? >>>>>>> >>>>>> The proposed solution will handle these. If you guys feel that it's >>>>>> too much/annoying to deal with, show me a repo and I'll send you the >>>>>> patches ;-) Please ? >>>>> >>>>> Alright, so the ebuild is here: >>>>> https://chromium-review.googlesource.com/#/c/347700/ (if you have a >>>>> Chromium OS chroot, it should just work). >>>>> >>>>> And the patches are here: >>>>> https://chromium.googlesource.com/chromiumos/third_party/mesa/+log/arc-11.3.0-pre1 >>>>> >>>>> They are still based on a slightly older version of mesa. Tomasz is >>>>> working on rebasing to the latest mesa master (it looks like someone >>>>> implemented similar changes to ours to add support for PRIME FD). >>>> >>>> Yeah, we've been building things up on top of the DRI loader >>>> extension, but now there is equivalent functionality upstream with DRI >>>> image loader, however somehow it doesn't work for us yet, I'm >>>> debugging it right now. >>>> >>> Some things that come to mind: >>> - do you have the render nodes created ? >>> - does drmGetNodeTypeFromFd() return the correct value ? >>> - does the assumption in get_native_buffer_fd() hold true on your >>> platform (gralloc implementation) ? >>> >> >> Yeah, we had this stuff running with very similar code before, so >> these points hold true. I'm getting some NULL pointer dereference in >> i965_dri.so, but didn't manage to dig into it yet. It's very likely to >> be related to our own addition rebased on top of new codebase. >> > Hmm this reminds me ... one of the Android-x86 guys spotted an issue > that was triggered with the "use dmabuf/rendernode" patches from Rob > H. I will forward you his analysis (note he's not at expert in the > area) in a moment. Thanks. Will surely be useful for further debugging. > > Have you guys, as a team or as a division of Google, considered > interacting more with the Android-x86 people ? I would imagine that > there will be benefits on both sides ? Well, I suppose there will be enough opportunities to interact, since I intend to upstream the Mesa changes we made. I can't say anything about non-Chromium projects, unfortunately. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev