ARMvX?

[BogDan]

Hi,

I'll try to clarify the things a little bit more:
We are talking about two separate set of libraries and tow separate sets of cpu flags:
1. The qt libraries used to compile your application.
This libraries are compile using official Android cpu flags for arm-v5 and for arm-v7a 

(without neon instructions), this cpu flags will be used also to compile your application.
This cpu flags are not tunned to use any cpu specific instructions set because 

we have to ensure your app will run on all platforms.
This libraries will be shipped by the SDK.


2. The qt libraries deployed by Ministro.

This libraries will use different cpu flags from the one shipped with the SDK, 

we'll try tune the cpu flags in order to run faster on specific cpus. Why ? 

Because even if your app is not compile with tunned cpu flags it will run 

faster because it will use libraries tunned for that cpu. Also most of 

the code run by the cpu it will be from Qt libraries not from your
application so it is very important to have cpu specific tunned qt libs.


I thinking to provied the following cpu configurations:
 - arm-v5 this one will be the same with the one shipped by the SDK.
 - arm-v6 without fpu 

 - arm-v6 with fpu 

 - arm-v7 without neon
 - arm-v7 with neon, even if neon can be detected at runtime and it is used 

in a few places in Qt I believe it will be better to compile everything using 

neon, because AFAIK gcc produces faster code when this flag is turn on.


Minsitro will check your cpu capabilities and will download appropriate
Qt libs for your cpu, so, your apps will use the best qt libs possible.
This is why I don't believe bundling qt libs into your package is a solution,
only for arm you'll need to ship 5 different libs to get the best performance.

Cheers,
BogDan.


>________________________________
>From: Espen Riskedal <espen at cutehacks.com>
>To: thomas.senyk at nokia.com
>Cc: bog_dan_ro at yahoo.com; necessitas-devel at kde.org
>Sent: Wednesday, August 31, 2011 4:46 PM
>Subject: Re: ARMvX?
>
>On Tue, Jul 19, 2011 at 9:49 PM,  <thomas.senyk at nokia.com> wrote:
>> Ah I see.
>>
>> This document helped me understand that Android has a solid definition (hadn't expected that) of what ABI versions it supports.
>> Now everything makes a lot more sense :)
>
>I agree, this was an eye opener. I think "CPU-ARCH-ABIS.html" should
>be required reading now! :D
>
>Summarized, at the moment there are three ABIs (this is from NDK v6b):
>
>"armeabi"
>- ARMv5TE instructions
>- no HW floating points
>- Thumb-1 (or ARM)
>
>"armeabi-v7a"
>- extends and is compatible with armeabi
>- adds ARM Architecture v7-a instructions
>- adds Thumb-2
>- adds HW floating points (vfpu) but calling conventions are kept
>compatible with armeabi
>- optionally adds: NEON and friends (should be detected at runtime)
>
>"x86"
>- Pentium Pro instruction set
>- MMX, SSE, SSE2 and SSE3 instruction set extensions
>
>My question then is, why do we plan to build for a lot more
>variations? On Linux NEON is detected at runtime, but we're planning
>non-NEON and NEON builds. Why?
>
>Another part that explained a lot to me:
>
>"It is also possible to build machine code for *two* distinct ABIs by using:
>
>   APP_ABI := armeabi armeabi-v7a
>
>This will instruct the NDK to build two versions of your machine code: one for
>each ABI listed on this line. Both libraries will be copied to your application
>project path and will be ultimately packaged into your .apk.
>
>Such a package is called a "fat binary" in Android speak since it contains
>machine code for more than one CPU architecture. At installation time, the
>package manager will only unpack the most appropriate machine code for the
>target device. See below for details."
>
>Let's hope Apple doesn't sue them for stealing the Universal binaries concept :D
>
>espen
>
>
>