[meta-intel] [OE-core] [Patch-v2 1/1] mesa: avoid unnecessary rerunning of tasks

[Otavio Salvador]

On Wed, Sep 11, 2013 at 1:46 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Mon, 2013-09-09 at 12:36 +0100, Burton, Ross wrote:
>> On 7 September 2013 00:56, Otavio Salvador <otavio at ossystems.com.br> wrote:
>> >> Maybe it is time to have a mesa-gl recipe alongside mesa that *just*
>> >> builds the GL libraries.  EMGD can depend on it for the driver modules
>> >> it installs, and presumably other vendors with binary drivers can
>> >> install it for the software rendering/GLX support (Otavio etc, please
>> >> step in here!).
>> >
>> > Yes; we have both situations at Freescale ARM BSP.
>> >
>> > For the AMD GPU binaries, which are used in MX5 SoCs we *just* use
>> > mesa GL and do software rendering.
>>
>> So mesa-gl will work fine there.
>>
>> > For Vivante GPU binaries, used for
>> > MX6, we use mesa GL *headers* but Vivante provides a libGL binary.
>>
>> My, that's horrific.  I'd forgotten about this, for good reason clearly.
>
> So I now have actual code which is better than any thought experiment :)
>
> First, I have this applied:
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t1&id=3e2c058ffab5b4e92523dac3078c1bc02d0eb8b8
>
> This creates a machine specific pkgdata/shlibs directory instead of the
> current multiple directories and iterations we use. Its not complete yet
> (buildhistory is broken for example), its another proof of concept. What
> this does is ensure that the main TUNE_PKGARCH directory doesn't get
> corrupted with emgd shlibs below, accidentally or otherwise.
>
> We then have two PoC patches one for OE-Core, one for meta-intel. These
> put the gl bits into "i586-emgd" instead of "i586" so they're isolated.
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t1&id=258e068bbb309877b6e36eeec1107806fc710cde
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/metaintel&id=917286eebc5e4eeb13fcc1b0db6adb50ccd847a0
>
> I hacked emenlow so it shared qemux86's TUNE_PKGARCH for testing
> purposes. You can then build both qemux86 and emenlow in the same build
> directory without them trampling clutter.
>
> cogl would also need to inherit the gl class so its rough around the
> edges but basically works.
>
> Thoughts?

Sorry by delayed reply.

I did look at the changes and I did enjoy it a lot. I had something
like this in O.S. Systems fork of OpenEmbedded-Classic to share
multiple builds against compatible geode machines... so let's stop
with nostalgy and focus in 2013 ;-)

It does looks great. I like the idea however I'd prefer if you could
name it like "subarch" or something like that. For example we have
some uses for this in FSL layer:

 * xserver-xorg
 * gpu-viv
 * amd-gpu
 * gst-fsl-plugin

All these are subarch compatible but currently are marked as machine
specific (which slow down builds).

Regards,

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750