On Wed, Sep 11, 2013 at 1:46 PM, Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > On Mon, 2013-09-09 at 12:36 +0100, Burton, Ross wrote: >> On 7 September 2013 00:56, Otavio Salvador <ota...@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 _______________________________________________ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel