Build/run B2G with hardfp

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
6 years ago
10 months ago

People

(Reporter: vlad, Assigned: _AtilA_)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [tech-p2])

Attachments

(5 attachments)

We should figure out how to do an Android/B2G build with hardfp for the performance boost it would provide.  This can use the same kernel, but will likely require new drivers (since they need to use the hardfp calling convention).  It's a really significant perf boost though, so it's worth looking into.
Proven perf win that's mostly a matter of build configuration changes.
Whiteboard: [tech-p2]
(Assignee)

Comment 3

6 years ago
I've being doing some investigations about this topic for a while, the main problem right now is that we need *all* the system to be built in hardfp mode, this includes propietary vendor libraries that are prebuilt with softfp.
I managed to build a toolchain that supports hardfp (besides generating hardfp code, the toolchain must have it's own libraries compiled with hardfp support, i.e. crt*.o stuff, libgcc, etc), this toolchain is built from the Linaro Android one with a gcc-4.6 based compiler.
I've modified the build system to use this toolchain with hardfp as ABI floating-point convention, and it compiled a lot of system libraries but there are some other Gonk stuff that needs to be linked with those softfp vendor propietary/specific libraries, so... it finally fails.
Here is how far I've come.
It would be great if some of our mobile vendor "partners" could provide their libraries with hardfp support.
Would you share the toolchain you built (or the recipe, since building new toolchains is so much fun!), plus patch to enable hard in build/?   We can easily recompile the world and evaluate performance.
(Assignee)

Comment 5

6 years ago
Created attachment 758224 [details] [diff] [review]
Changes the default toolchain to mine and CFLAGS to hard-float
(Assignee)

Comment 6

6 years ago
Created attachment 758226 [details] [diff] [review]
NDK build system changes to use my toolchain
(Assignee)

Comment 7

6 years ago
Created attachment 758230 [details] [diff] [review]
Change armv7-a Neon config to use hardfp
(Assignee)

Comment 8

6 years ago
Created attachment 758231 [details] [diff] [review]
Changes armv7-a config to use hardfp
(Assignee)

Comment 9

6 years ago
Created attachment 758235 [details] [diff] [review]
Changes adbs tool to point to my toolchain
(Assignee)

Comment 10

6 years ago
ouch! .. I could have provided a one patch file :( ... sorry for the noise.
The toolchain is for linux 32bits hosts, and the target is for armv7-a (and NEON if needed) devices. It has been uploaded to: https://dl.dropboxusercontent.com/u/18328346/arm-linux-androideabihf-4.6.tar.bz2

Anyway, as said before we cannot build the whole system until vendors could provide us hardfp versions of their prebuilt libraries :(
(In reply to Juan Gomez [:_AtilA_] from comment #10)
> Anyway, as said before we cannot build the whole system until vendors could
> provide us hardfp versions of their prebuilt libraries :(

Yep.  

Thanks for the patches.  We'll take a look at this soon

Updated

6 years ago
Depends on: 843911

Updated

6 years ago
No longer depends on: 843911
(Assignee)

Comment 12

6 years ago
Just for the record, I've asked for help to Geeksphone. It would be great if they can provide the source code of their libraries..

http://forum.geeksphone.com/index.php?topic=5476.0
Michael, any results from comment #11?
Flags: needinfo?(mvines)
The lack of hardfp compiled prebuild libraries may no longer be blocking the building of b2g to use the hardfp ABI, see bug 942561.
(In reply to Dietrich Ayala (:dietrich) from comment #13)
> Michael, any results from comment #11?

It's totally doable and we should be able to share hard binaries for this, "soon" just hasn't quite arrived yet I guess.  v1.4 feels nice for this.  @mwu and I where chatting about this a little while ago actually.
Flags: needinfo?(mvines)
Yeah I've been spending some time this week figuring out the build system for the Android toolchain.
Assignee: nobody → mwu

Comment 17

5 years ago
Great, we need hardfp especailly on such weak hardware like hamachi! I can test hardfp on my hamachi when it will be available! Just give me a sign!

Comment 18

5 years ago
I'm just waiting for it, it'll be NO2 for One Touch Fire!

Comment 19

5 years ago
Great, I'm waiting for hardfp for Firefox OS ;)

Comment 20

5 years ago
Good news, I'm waiting :)
Depends on: 956606

Comment 21

5 years ago
Could you tell me if bug 962733 is related to enabling hardfp on hamachi?
(Assignee)

Comment 22

5 years ago
(In reply to mac from comment #21)
> Could you tell me if bug 962733 is related to enabling hardfp on hamachi?

No, it is not.
_AtilA_ is investigating this currently.
Assignee: mwu → atilag
Is there any update on the status here?  Would love to squeeze some more perf out of RPi ;).
(Assignee)

Comment 25

4 years ago
Last thing I was trying to do, was making a proof of concept tiny program and see how to compile it with google toolchain, mixing hardfp and softp, but I was getting crashes from the compiler itself. As soon as I close other bugs I'm working on I'll resume this one!
(Assignee)

Comment 26

4 years ago
Ok, I'm back on this.
Very excited to see if this is finally possible and what's the performance boost!
(Assignee)

Comment 27

4 years ago
UPDATE: I'm planning to address this task in two ways:
1. Try to compile the whole system with HardFP support. 
I could compile the entire Gonk with hardFP in the past, using a Linaro toolchain configured and compiled by me. Now I'm using latest Android toolchain (gcc-4.9, which has *real* HardFP support), to compile a JB4.2 based Gonk (Flatfish actually). It's being kind of hard because JB4.2 is officially compiled with a gcc-4.6 toolchain. If I cannot make it, I'll try to jump to a KK based device (Flame, of course).

2. Try to compile just Gecko in HardFP mode.
I read that there's a way to mix HardFP and SoftFP code by wrapping SoftFP code with some compile attributes. This will be my next task to test, and probably a solution for older devices based on ICS (like RPi.. I don't care the others :P).

To address both tasks, I need to migrate Gecko to gcc-4.9 so I'll try to help with bug 1087161 as well. 

I'll keep you updated. Stay tuned :)
Depends on: 1087161
(Assignee)

Comment 28

4 years ago
UPDATE: Long time since my last update, sorry.
I'm trying to build a simple PoC (hello world program) with HardFP support, and my goal it's just to run the program in the real hardware (Flatfish). I managed to change the build system for compiling with HardFP so I could compile Bionic with Hardfp support as well. This way I'm supposed to build my PoC, push it with the rest of binary dependencies (libc, libstdc++, libdl, /system/bin/linker, etc) into the device and run it like: 
LD_LIBRARY_PATH=. ./test-hard
I already managed to compile the PoC and dependencies, but when I run it, it is segfaulting (and I'm pretty sure it's not a bug in the code), ... so I'm trying to figure out what's wrong.
My bet, some Bionic incompatibility.
(Assignee)

Comment 29

4 years ago
UPDATE: I needed to switch to KK based device (Flame), because my Flatfish died :(. I've managed to compile Gonk and Gecko with hardfp!, it was far more easy than using JB. My first attempt after flashing it, is of course, a black-screen that I'm investigating.
(Assignee)

Comment 30

4 years ago
UPDATE: Good news, I have a hardfp ABI version of Gecko running on my Flame :) . Of course, it's not stable enough yet. So now I'm gonna locate where are the incompatbilities and try to fix them.
I think that the only way to make HardFP and SoftFTP ABIs compatible is by building a "wrapper" library that transforms from one ABI to other. If __attribute__((pcs("aapcs"))) sufix works as I expects, this shouldn't be as hard as it sounds. The hard part here is to locate the functions in vendor libraries which use double-precision types as arguments/retun values, and see if we are using them to add them to the wrapper.
(Assignee)

Comment 31

4 years ago
UPDATE: After figuring out what are the library dependency tree of b2g, includind dyanimc loaded libraries too (I built an interesting tool to accomplish this, I'll upload it soon to Github). After compile them all in Hardfp mode I could run a much more stable hardfp version of Gecko. Indeed, I've been playing around for a while with no crash so far. In the meantime I was looking for any function which uses double-precission on it's arguments over vendor libraries, but I didn't find anyone yet...
I was trying to run performances tests too, using the new tool: Raptor, but it's not working for me so I'll ask for help to the owner because I'm eager to see which is the real performace gain on this.
(Assignee)

Comment 32

4 years ago
Something I didn't mention, but I think it's important. This setup: Gonk with softfp and Gecko with hardfp, implies having two version for some of the libraries.
(Assignee)

Comment 33

4 years ago
UPDATE: Before continuing working with all the patches needed to build a Hardfp version of Gecko and all it's libraries, I want to run performance tests and evaluate the numbers to see if it's worth all the effort. Raptor (our brand new perf test framework), is not fully working for me so I'm trying to figure out what's going on... In the meantime, bug 1087161 has my attention (as a blocker) and hope to close it soon.
(Assignee)

Comment 34

3 years ago
UPDATE: Long time since I update the status, so let's go. 
I've been working on landing the gcc-4.9 toolchain upgrade (bug 1087161) and in the meantime, I tried to make Raptor tool works for this HardFP ABI version of Gecko and get some premature numbers, but they weren't so impressive because the Raptor tool tests things that are not going to be boosted by just improving single/double-precision operations... for the moment, let's see in a future :). I figured out a way to make both ABIs, Soft and Hard coexist by just appending an __attribute__ tag in all functions which use double and float arguments, so there's no need to make an ASM wrapper (thank goodness!), I have patched Bionic, Android build system, Gecko build system... and made some tools to handle the mix of binaries as well as stabilizing some parts of Gecko which behave wrong.
There's still some work to do, but the basics are done. I'll open bugs for all the tasks we need to fix/accomplish in order to land all this work.
And in the meantime, I'll try to run our statistical profiler (thanks Dave Hylands ;)) and talk to GFX guys so the can advise me on how to test graphics parts (the ones I expect more improvement).
(In reply to Juan Gomez [:_AtilA_] (CEST) from comment #34)
> And in the meantime, I'll try to run our statistical profiler (thanks Dave
> Hylands ;)) and talk to GFX guys so the can advise me on how to test
> graphics parts (the ones I expect more improvement).

You should ping the asm.js/OdinMonkey people, they're running FP tests compiled from C/C++ so they should be able to measure improvements easily.
(In reply to Gabriele Svelto [:gsvelto] from comment #35)
> (In reply to Juan Gomez [:_AtilA_] (CEST) from comment #34)
> > And in the meantime, I'll try to run our statistical profiler (thanks Dave
> > Hylands ;)) and talk to GFX guys so the can advise me on how to test
> > graphics parts (the ones I expect more improvement).
> 
> You should ping the asm.js/OdinMonkey people, they're running FP tests
> compiled from C/C++ so they should be able to measure improvements easily.

Odin uses a hardfp style calling convention internally, between asm.js functions, passing some floats in float registers, so these might not show a difference unless they are calling external library code.

Comment 37

10 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.