NEON vs. 3D acceleration


G

guest

Guest
Hi,

on the startpage on openpandora.org it says that the pandora has a ARM NEON FPU.

To use this unit the OS and all the software need to have a build with the "hard floating point" gcc-flag.

The problem is, that you cannot mix up hard-float software with soft-float software.

The binary SGX-Driver was build with "soft-float"

so only binary 3d-acceleration OR the neon co-processor can be used. We all know, 3d-acceleration is working, so the co-processor cannot be used.

why is openpandora.org attracting possible buyer with the availability of the co-processor which is unusable (with the default distro) ?

Or maybe i'm wrong?

thx

sry for ma bad englisch ;)
 
Both the 3D accelerator and NEON are being used. PCSX ReArmed is a prime example of the benefits of NEON. It gained a huge speed boost when large chunks of the floating point were converted to NEON instructions.

Regarding mixing hard and soft float, that's just function calling convention. With hard float, all functions that take floats are passed arguments in actual floating point registers. With soft floats, the floats go through some conversion in order to be passed through integer registers, but once they get there they are converted back to floats again. It doesn't say anything about how the floats are actually treated once they get into the function. (*)

There is absolutely no reason you can't call a function with either soft or hard floats, and then have that function dump the arguments onto the NEON processor or whatever it needs to do.

Even if that were a problem, it still wouldn't prevent you from building one object with hard floats for NEON, another object with soft floats for GPU, and a third object capable of performing conversions between the two. Fortunately it isn't a problem, that workaround would get messy.

So yeah, you're wrong. All co-processors in the Pandora are totally usable without restriction if you take the time to learn to use them.

edit (*) Exophase will be along to tell me I'm grossly oversimplifying and/or saying something wrong here eventually. :p
 
Last edited by a moderator:
So... some dinkus just trying to stir up a hornets nest or something? Should I be offended?
 
Both the 3D accelerator and NEON are being used. PCSX ReArmed is a prime example of the benefits of NEON. It gained a huge speed boost when large chunks of the floating point were converted to NEON instructions.


Regarding mixing hard and soft float, that's just function calling convention. With hard float, all functions that take floats are passed arguments in actual floating point registers. With soft floats, the floats go through some conversion in order to be passed through integer registers, but once they get there they are converted back to floats again. It doesn't say anything about how the floats are actually treated once they get into the function. (*)


There is absolutely no reason you can't call a function with either soft or hard floats, and then have that function dump the arguments onto the NEON processor or whatever it needs to do.


Even if that were a problem, it still wouldn't prevent you from building one object with hard floats for NEON, another object with soft floats for GPU, and a third object capable of performing conversions between the two. Fortunately it isn't a problem, that workaround would get messy.


So yeah, you're wrong. All co-processors in the Pandora are totally usable without restriction if you take the time to learn to use them.


edit (*) Exophase will be along to tell me I'm grossly oversimplifying and/or saying something wrong here eventually. :p

thx for your reply!

i only know the -mfloat-abi=soft or -mfloat-abi=hard gcc-flags. I figured out, there is also a -mfloat-abi=softfp flag which has something to do with the calling conventions you talked about. So this means the pandora software is compiled with the -mfloat-abi=softfp flag?
 
Yeah we use softfp, so we can use both NEON and GPU simultaneously without problems. The only difference between softfp and hard is the ABI (argument passing thing WizardStan mentioned), so if you pass args with pointers to some structures with floats or floats themselves, there is no difference to hard at all.

PCSX ReArmed is a prime example of the benefits of NEON. It gained a huge speed boost when large chunks of the floating point were converted to NEON instructions.
FYI PCSX ReARMed doesn't use floats at all, it's purely integer. The NEON code helps purely because NEON is a SIMD unit - Single Instruction Multiple Data, which means the code can process multiple pixels in single operation.
 
Last edited by a moderator:
FYI PCSX ReARMed doesn't use floats at all, it's purely integer. The NEON code helps purely because NEON is a SIMD unit - Single Instruction Multiple Data, which means the code can process multiple pixels in single operation.
Oh neat. I didn't actually know that. I should really investigate the power of the NEON processor one of these days.
 
It's a bit like the MMX instructions in x86. Instead of working with 32 bit registers (words), you can work with double words or quad words (64/128 bit registers), and use them as vectors of 32, 16 or 8 bit integers. So for example one quad-word register could store 16 8-bit values. You have instructions for addition, multiply etc that work on these vectors. You can do simple image operations in less than one instruction per pixel in this way.
 
Back
Top