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

[Koen Kooi]

Op 6 aug. 2012, om 14:43 heeft Richard Purdie <richard.purdie at linuxfoundation.org> 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 <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.
> 
> 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).

> 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.

Executive summary: ARM SoCs with 3d suck, Intel parts with 3d sucks less. It's a mess in oe-core.

regards,

Koen