Sounds good! Have you uploaded the results to OpenBenchmarking.org? I can see that it seems that someone has conducted some tests on this platform, but there are no test results available:
http://openbenchmarking.org/s/efika%20mx

Also, does anyone know if the default Genesi Ubuntu 10.10 is with hard float enabled or does it use soft float?

It is not done with hard-float. If we were to make a release, you would lose the ability to use 3D graphics (the driver requires a binary blob that even we don't have access to rebuild)

_________________
Steev Klimaszewski, Genesi USA Inc.
Senior Software Engineer

I see. That's a shame.

Would you care to elaborate a bit on why the 3D driver needs to be rebuilt if you rebuild the kernel with hardfp support? I presume this is needed, although I haven't completely understood what it takes for a system to execute a program that uses these VFP-specific instructions.

Is it necessary for the kernel to be built with hardfp support in order to pass on these instructions from a user-space program to the VFP co-processor?

And if this is the case, why can't the 3D driver just not use these VFP-specific instructions while the kernel does?

The problem is a binary blob (a static library in particular) that is linked to the 3d drivers, which is absolutely needed. This is built using the softfp ABI, and it is not possible to produce hardfp versions of the 3D drivers unless we manage to have a hardfp version of that static library as well. This is however difficult for us as we don't have the source code to do the compilation ourselves. So we have to convince upstream to produce the hardfp version. It's not impossible, and if you ask me it's going to happen sooner or later, we just have to wait a while.
The kernel has nothing to do with it, it's a userspace library that needs to be ported.
It does, the kernel doesn't use VFP instructions at all, it's just a userspace library built with an incompatible ABI (softfp vs hardfp). It will happen, and when it does powerdeveloper.org will carry the news first you can be sure of that :)

Thanks for explaining. I think I understand it somewhat better now.
The issue is related to incompatible ABIs, where if, for example, we compile glxgears with the hard-float ABI we won't be able to link it to the necessary library containing an OpenGL implementation for this GPU, if this library is compiled using the soft-float ABI.

I'm glad you expect this to happen at some point, cause that was going to be my next question :) - why a hard-float blob hasn't been released already. When Genesi buys hardware that uses the GPU in question and is in need of this library, you'd think the GPU manufacturer would be more eager to give you this library if it can improve performance on hardware that uses their GPU.
But again, I don't know much about the issue, it could be non-trivial releasing this library in a hard-float version.

Without getting into specifics, one of the main reasons is that there isn't a widely used hardfloat toolchain/implementation out there. We're working on it, and once we finish, it will be easier to get the right people who produce that blob to create it. Until there is an actual demand though, there isn't much we can do.

_________________
Steev Klimaszewski, Genesi USA Inc.
Senior Software Engineer

I see. Genesi is just ahead of everyone else :).

I'm really looking forward to the i.MX53-based Smartbook, I think I'll wait until this comes out before I dive into ARM-land. Unless it takes too long and I lose my patience :).

Cheers!

This is a historical issue. Before the advent of ARMv6 (e.g. the ARM11 core in the first iPhones), there was a profusion of different and incompatible FPU implementations for ARM. Nowadays, almost all ARM implementations have some kind of vfp3 variant in them, at least a vfp3-d16 (which implements only 16 double registers, instead of 32).

The toolchains were designed to pass all FP arguments in integer registers for the plain reason that if a CPU lacked the VFPv3 (or another compatible variant), then there was no possibility of using FP registers at all - unless in integer registers. The FPU can be emulated in integer math, but its registers cannot. Hence, the softfp ABI was a trade-off that could still use a FPU if one existed, but would work without.

The world has moved on, now we have a VFPv3 implementation in all the chips that are relevant to Desktop (or Notebook) Linux in any way. So it's about time to build toolchains for hard float (passing params in FPU registers).

The biggest perf hit comes from the fact that to convert a set of variables from integer to FP registers takes a huge performance hit in the initial setup code of a function. Just look at an 'objdump --disassemble' output of any program that uses FPU and the softfp ABI.

topi