Am 27.11.2012 19:39, schrieb Lukas Märdian:
Am 26.11.2012 20:25, schrieb Martin Jansa:
On Mon, Nov 26, 2012 at 08:10:11PM +0100, Denis 'GNUtoo' Carikli wrote:
On Mon, 26 Nov 2012 12:49:31 +0100
Martin Jansa <martin.ja...@gmail.com> wrote:
2) To get -mtune back we can set more specific DEFAULTTUNE for all
SHR supported devices in distro config, so that binary feed will be
renamed from armv7a-novfp-neon to cortexa8-novfp-neon and
cortexa9-novfp-neon.
+ "better" performance on tuna, same on nokia900, om-gta04, crespo
- extra disk space needed for separate cortexa9-novfp-neon feed
(armv7a-novfp-neon will be removed - replaced by
cortexa8-novfp-neon)
- 33% longer build time for all SHR supported machines (3 package
archs instead of 2)
I think that's the way to go but I've some comments on that:
* SHR does support tuna? I don't think it's well supported since no
one is working on it for SHR.
It's built on official buildhost so from this POV it's supported and it
has more atention then e.g. nokia900 and crespo..
* SHR hasn't got a very powerfull buildhost, so we could skip building
tuna on the official SHR buildhost until someone steps in and
supports it?
SHR buildhost is using danny branches, so not problem now. The problem
is for devs using shr or jansa/test branches and building tuna together
with other armv7a devices just because it's almost "for free" as it
reuses whole feed and sstate-cache.
* Openwebos supports tuna and has a powerfull buildhost. does it have
cortex a8 machines? the HP touchpad?
Powerfull buildhost is not yet in use and tuna is the only armv7a
device built by webos-ports jenkins (at last now), so no problem here.
So I think we could do 2) in a way that won't impact build a lot.
would be nice to have some benchmarks to see how much (if anything at
all) we gain by using -mtune and especially -mtune=cortexa8/a9 diff.
FWIW: I can already provide SHR images for tuna/nokia900/om-gta02 built without
-mtune.
Benchmarks seem to be a good idea. If it is of real benefit I'd vote for
(2) as well, as that is what we have OE for – device specific
optimization. If we'd just use "generic" package architecture, we'd
probably be better of using Debian as a base, which already provides this.
If there is no performance win, though, we should choose the option
which our buildhost can provide, so we'd have one problem less: search a
new/better buildhost.
For SHR I can only second this. Imho it's better to continue what we're
doing all the time: device specific building. A real problem for SHR is
the builder now for a long time. Maybe it's worth a try to start
searching for a new one here.
I vote for (2) as well.
regards,
Simon
--
Simon Busch - http://mm.gravedo.de/blog/
_______________________________________________
Shr-devel mailing list
Shr-devel@lists.shr-project.org
http://lists.shr-project.org/mailman/listinfo/shr-devel
