From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Burton, Ross" <ross.burton@intel.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>,
openembedded-core <openembedded-core@lists.openembedded.org>,
"meta-intel@yoctoproject.org" <meta-intel@yoctoproject.org>,
Darren Hart <darren.hart@intel.com>,
Saul Wold <saul.wold@intel.com>
Subject: Re: [Patch-v2 1/1] mesa: avoid unnecessary rerunning of tasks
Date: Wed, 11 Sep 2013 17:46:07 +0100 [thread overview]
Message-ID: <1378917967.3484.199.camel@ted> (raw)
In-Reply-To: <CAJTo0LYUL1kvZB=Lk8ine+zVpAipRNMevnnpLi5C2_+ZobLdyw@mail.gmail.com>
On Mon, 2013-09-09 at 12:36 +0100, Burton, Ross wrote:
> On 7 September 2013 00:56, Otavio Salvador <otavio@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?
Cheers,
Richard
next prev parent reply other threads:[~2013-09-11 16:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1378361078.git.nitin.a.kamble@intel.com>
[not found] ` <2b4e12bfea634eaecac61b471a9d607fe127d1cd.1378361078.git.nitin.a.kamble@intel.com>
2013-09-05 8:33 ` [Patch-v2 1/1] mesa: avoid unnecessary rerunning of tasks Richard Purdie
2013-09-05 11:52 ` Richard Purdie
2013-09-05 13:00 ` Otavio Salvador
2013-09-06 18:36 ` Burton, Ross
2013-09-06 23:56 ` Otavio Salvador
2013-09-09 11:36 ` Burton, Ross
2013-09-11 16:46 ` Richard Purdie [this message]
2013-09-13 21:09 ` Otavio Salvador
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1378917967.3484.199.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=darren.hart@intel.com \
--cc=meta-intel@yoctoproject.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio@ossystems.com.br \
--cc=ross.burton@intel.com \
--cc=saul.wold@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox