Closed Bug 845086 Opened 12 years ago Closed 7 years ago

Build/run B2G with hardfp

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: vlad, Assigned: _AtilA_)

References

Details

(Whiteboard: [tech-p2])

Attachments

(5 files)

Changes the default toolchain to mine and CFLAGS to hard-float
1.01 KB, patch
Details | Diff | Splinter Review
NDK build system changes to use my toolchain
560 bytes, patch
Details | Diff | Splinter Review
Change armv7-a Neon config to use hardfp
405 bytes, patch
Details | Diff | Splinter Review
Changes armv7-a config to use hardfp
437 bytes, patch
Details | Diff | Splinter Review
Changes adbs tool to point to my toolchain
886 bytes, patch
Details | Diff | Splinter Review
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]
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.
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
Depends on: 843911
No longer depends on: 843911
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
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!
I'm just waiting for it, it'll be NO2 for One Touch Fire!
Great, I'm waiting for hardfp for Firefox OS ;)
Good news, I'm waiting :)
Depends on: 956606
Could you tell me if bug 962733 is related to enabling hardfp on hamachi?
(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 ;).
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!
Ok, I'm back on this. Very excited to see if this is finally possible and what's the performance boost!
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
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.
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.
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.
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.
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.
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.
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.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: