Floating Point


dockthepod

Member
Joined
Jun 15, 2006
Messages
250
I've looked over the docs and searched google but am a bit confused. This processor seems to have support for floats but is it "free" (ie, just code normally and it will compile to use the HW correctly) or do we need to explicitly use NEON instructions? (wtf is NEON exactly anyhow?) Will we get good performance with floats or would fixed point still be much faster?

I'm starting to hack on a new 3d engine for pandora and want to make sure I don't dig myself into a hole using floats rather than fixed point :)
 
You can either use the NEON or the built in FP support, the built in isn't the fastest but it runs quake2 etc fine.
 
The Cortex A8 has 2 major FP data paths, one handles VFP-lite operations and the other Neon (they cannot work in parallel). The VFP-lite is there for IEEE compliance and backwards compatibility, it is well developed and widely supported. By default GCC will output VFP-lite code, whereas new-ish versions of GCC support Neon operations via a command line parameter.

The VFP-lite can perform non-pipelined float and double operations.

The Neon unit is pipelined but cannot work with doubles. It's also SIMD, but i am unsure how much this impacts performance.

Overall, there's really no need to use fixed point over floats, Look at the Quake 2 video.
 
A lot of common single precision VFP operations can be performed on the NEON unit if certain conditions are met. But it's a little unclear as to whether or not this has been triggered so far. Some benchmarking would help determine this.
 
This topic caught my interest :)

Is your new 3D engine from scratch or on top of GLES?

If your new 3D engine is on top of GLES, then definitely use floats since most of the performance hit will be hidden by the powervr chip.

If your new 3D engine is NOT on top of GLES then you should consider vectorizing the engine to run on the Neon processor. The advantages of this is that 1) floating point is supported for sure at full speed, 2) the engine would likely be faster than the Quake II engine, 3) more CPU time could be dedicated to the application rather than rendering. The downside is that it may require writing some code in assembly.

I suspect that the DSP chip could also be used to create a 3D engine.

Regarding Quake II, the engine is running in software mode (i.e. not using GLES / powervr chip) and I presume that it is not even vectorized to use the Neon instruction set.

Good luck,
Jeff
 
jboody said:
This topic caught my interest :)

Is your new 3D engine from scratch or on top of GLES?

If your new 3D engine is on top of GLES, then definitely use floats since most of the performance hit will be hidden by the powervr chip.
No it wont. There is a lot of floating point code going into scene graph, billboards, animations and related stuff, all of which will be executed on the main CPU.

There is no way around this code ( short of going fixed point) so it is a very , very good thing we have built in FP unit.
What is true is that most of that code doesn't need to go beyond basic floats and thus it might be advantageous to use NEON to vectorize at least some of this stuff.
As soon as I get my unit, I am going to see how fast NEON is in relation to the main FP unit.
 
Last edited by a moderator:
warmi said:
As soon as I get my unit, I am going to see how fast NEON is in relation to the main FP unit.

As others wrote, since the VFPlite isn't pipelined and NEON is SIMD and pipelined, I would expect carefully written and scheduled assembly code to be at the very least twice faster on NEON :)
 
Last edited by a moderator:
Are there any performance penalties for converting from float to int, or vice-versa, such as the Xbox 360 has? It requires the value to be written to memory to be moved from integer unit to floating point unit, and you cannot immediately read the memory you just wrote to. You have to wait for the write to complete before reading it again. Does this apply to the FP or NEON on the OMAP?
 
Back
Top