[OE-core] [PATCH V3 00/11] Mesa upgrade/improvements

[Koen Kooi]

Op 3 aug. 2012, om 15:19 heeft Ross Burton <ross.burton at intel.com> 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.

>> [1] The best solution if of course getting sgx support into mesa, but nothing is happening on that front apart from some posturing on the fsf side, no actual code.
> 
> HahahHAHAHAHahha.  (wipes tears from eyes)  The FSF can posture all they want (wasn't aware they'd done that as the code is clearly closed source), but I can't see Imagination opening all their code any day soon.

It's a reverse engineering effort in which only FSF marketing is involved. Their idea is right, look at the Mali and Adreneo RE work, that's coming along nicely.