Op 6 aug. 2012, om 16:04 heeft Richard Purdie <[email protected]> het volgende geschreven:
> On Mon, 2012-08-06 at 15:24 +0200, Koen Kooi wrote: >> Op 6 aug. 2012, om 14:43 heeft Richard Purdie >> <[email protected]> het volgende geschreven: >> >>> On Fri, 2012-08-03 at 17:46 +0200, Koen Kooi wrote: >>>> Op 3 aug. 2012, om 15:19 heeft Ross Burton <[email protected]> het >>>> volgende geschreven: >>>> >>>>> On Friday, 3 August 2012 at 11:18, Koen Kooi wrote: >>>>>> libegl and libgles aren't built nowadays, so the problem is >>>> avoided. Noone has dared to touch this subject the past 2.5 years: >>>> http://cgit.openembedded.org/openembedded/commit/recipes/mesa?id=3d96f8cb61225d515b5cb4fe863f0d50c3ced436 >>>>>> >>>>>> The best solution[1] is to disable egl/gles in the mesa-recipes and >>>> add a seperate recipe for them. That way you still get glu and other >>>> useful mesa bits needed for gnome/efl/xfce/etc, but you can skip the >>>> sysroot/shlib poisoning if needed. >>>>> After much digging I see that the Beagle PVR drivers only provide >>>> gles and egl, which is why you say that the problem was avoided. Of >>>> course that's just one specific driver, for example the Cedar Trail >>>> EMGD driver does build libgl, libgles and libegl. >>>>> >>>>> If the solution is "put the egl/gles bits in another package" >>>> >>>> Recipe, not package. Big difference :) >>>> >>>>> then I'm totally confused as to what the actual problem is. >>>> Considering there's numerous libegl libraries for the many variants of >>>> PVR on ARM, I'm struggling to understand exactly what is new here. >>>>> >>>>> Can you explain clearly what the problem is, I'm obviously missing >>>> something. Once I understand the problem I can help with a solution. >>>> >>>> You need mesa for the !egl and !gles libs and evil vendor blob for egl >>>> and gles libs. In the emgd case you can get gl from the evil vendor as >>>> well. To build e.g. EFL I need mesa for the !egl and !gles bits, to >>>> build EFL with gles support I need mesa (again !egl, !gles) in >>>> addition to evil vendor blob for egl and gles. >>>> We could make this work with MACHINE_FEATURES or something similar, >>>> but that would mean that a very large chunk of userspace now becomes >>>> machine specific. This is how clutter worked in the past and just look >>>> at the fit the canonical/linaro people threw when they started doing >>>> 'embedded' and clutter. >>>> >>>> To compress the above: you need to build both the mesa and the >>>> evil-egl-binary *recipes* for things to work, so the egl bits should >>>> be a different recipe, not a subpackage of the mesa recipe. This is >>>> all assuming we care abou the binary blobs e.g. TI distributes for 3d >>>> support. If you don't, fine, merge this patchset. >>> >>> Let me test this a little bit more. The binary blobs shipped by TI would >>> be machine specific >> >> They aren't machine specific, they contain multiple blobs to support a >> wide range of SoCs. But even if they were machine specific it wouldn't >> work like you want to. >> >>> and would be marked as such in the package feeds? >>> The mesa pieces would be marked as architecture specific and more >>> generic. In feeds, machine specific has priority so on the machines >>> where there is hardware support, the hardware optimised versions would >>> get installed? >> >> You're assuming all libraries are subpackaged into their own package >> and renamed identically, they aren't (which is actually a feature in >> the current situation). > > They don't have to be renamed identically, the would have to have > RPROVIDES that cover what is needed in some standard namespace. > >>> If the above isn't the case, can we make it work like that? >> >> We can't. Even if we could, it would be a giant step backwards for >> people using the output of the build (see below). >> >> The only solution that keeps the good things of the current situation >> is to have the following recipes: >> >> 1) mesa (does not build libgl or libgles) >> 2) mesa-gles (only builds libgl+libgles) >> 3) evil-vendor-blob >> >> And you can specify per SoC something like >> PREFERRED_PROVIDER_virtual/egl = "mesa-gles" or >> PREFERRED_PROVIDER_virtual/egl = "evil-vendor-blob". >> >> That will cause problems if you are building for 2 SoCs in the same >> architecture family that need different gl providers, the shlib code >> might get a bit upset. I don't have a good solution for that, but we >> have that problem right now as well. >> >> From the build side we could make it a bit prettier by making all the >> gl stuff machine specific, but that will be a giant pain in the ass >> for the end user (distro maintainer, $silicon_vendor customer, >> $silicon_vendor SDK). >> >> If we end up doing it like that, we'll need buy-in from the silicon >> vendors involved to change the way they distribute their blobs. That >> is doable, I managed to get the TI blobs changed a few times in the >> past, but it's a slow process. >> And everything using GL would suddenly be machine specific, I hope the >> yocto autobuilder can keep up with that. > > Everything does not have to become machine specific if the things in > question have known good portable APIs. As I understand it we have GL so > we can swap in the binary blobs in place of the generic ones without > needing everything to be machine specific. > >> Executive summary: ARM SoCs with 3d suck, Intel parts with 3d sucks >> less. It's a mess in oe-core. > > Ok, we need to do something about this mess, period. Its not going to > get any better and we need to sort it out. I can't "force" changes in > but on the other hand I'm not going to tie the hands of everyone just > because the ARM world in particular is a total mess in this area. I completely agree with that! > As such, I'm likely going to allow architecture overrides in core mesa > so for example, IA can enable gles and egl for everyone and cleanup > their binary blobs to override them on platforms where it makes sense. I > suspect someone will start sending patches to enable a generic arm core > and I am going to have a *really* hard time refusing the patches due to > any one silicon provider's binary blob issues. Every GPU on arm has evil blobs, Mali, Adreno, SGX, etc. The RE efforts for Mali and Adreno are making good progress, though. > IMO, the evil-vendor-blob recipes need to start generating packages > which are machine or platform specific and those platforms need to > correctly list those feeds as being compatible, providing a set of > standard things which allow replacement of the core generic architecture > providers. There's no such thing as platform specific packages, yet. > How does that sound? Sounds pretty good. regards, Koen _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
