All times are UTC-06:00




Post new topic  Reply to topic  [ 23 posts ] 
Author Message
 Post subject:
PostPosted: Sun May 08, 2011 6:53 am 
Offline

Joined: Sun May 01, 2011 6:12 pm
Posts: 42
Location: Denmark
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?


Top
   
 Post subject:
PostPosted: Mon May 09, 2011 1:15 pm 
Offline
Genesi

Joined: Tue Feb 07, 2006 4:49 pm
Posts: 145
Location: San Antonio, TX
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


Top
   
 Post subject:
PostPosted: Mon May 09, 2011 3:57 pm 
Offline

Joined: Sun May 01, 2011 6:12 pm
Posts: 42
Location: Denmark
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?


Top
   
 Post subject:
PostPosted: Mon May 09, 2011 5:25 pm 
Offline

Joined: Wed Oct 13, 2004 7:26 am
Posts: 348
Quote:
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.
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.
Quote:
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?
The kernel has nothing to do with it, it's a userspace library that needs to be ported.
Quote:
And if this is the case, why can't the 3D driver just not use these VFP-specific instructions while the kernel does?
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 :)


Top
   
 Post subject:
PostPosted: Tue May 10, 2011 12:13 pm 
Offline

Joined: Sun May 01, 2011 6:12 pm
Posts: 42
Location: Denmark
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.


Top
   
 Post subject:
PostPosted: Tue May 10, 2011 2:32 pm 
Offline
Genesi

Joined: Tue Feb 07, 2006 4:49 pm
Posts: 145
Location: San Antonio, TX
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


Top
   
 Post subject:
PostPosted: Tue May 10, 2011 4:45 pm 
Offline

Joined: Sun May 01, 2011 6:12 pm
Posts: 42
Location: Denmark
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!


Top
   
 Post subject:
PostPosted: Wed May 11, 2011 4:03 am 
Offline

Joined: Mon Apr 25, 2011 6:50 am
Posts: 3
Location: Netherlands
Quote:
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.
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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 23 posts ] 

All times are UTC-06:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
PowerDeveloper.org: Copyright © 2004-2012, Genesi USA, Inc. The Power Architecture and Power.org wordmarks and the Power and Power.org logos and related marks are trademarks and service marks licensed by Power.org.
All other names and trademarks used are property of their respective owners. Privacy Policy
Powered by phpBB® Forum Software © phpBB Group