Issues With Using Neon In The A8...

[Svartalf]

http://hardwarebug.org/2008/12/31/arm-neon-memory-hazards/

According to this article, here's some ugly sharp edges with NEON use. While it's pipelined, it's async in nature from the A8 itself, meaning there's some memory access hazard prevention silicon in place in the SoC. The CPU and NEON trip all over each other if the NEON's access spans a 16-byte boundary. Timings get pretty evil when this happens (Anywhere from the "nice" 22 cycles to the truly evil 52 cycles to complete an ARM store to RAM immediately in the same domain as a NEON store operation.

Just thought everyone ought to know that one...

 

[mali]

I think it'd be a good idea to create a sticky NEON thread with all the info people can find about NEON and its hurdles. NEON/FP is Cortex' Achille's heel, it seems. This link was already posted. Things get burried too fast here IMO.

 

[Squidge]

Or perhaps the info can be placed in the Pandora wiki, which is stickied to this forum. If we can stick with one stickied post, it would be much better IMO.

 

[maciek_urbanski]

But let's put things into context here. Doing any stores straddling cache line boundary is asking for trouble in any architecture. In x86 land only Intel i7 (Nehalem) does this (almost) for free.
Two store units and NEON being asynchronous is a benefit really. And since NEON has a ARM to NEON register transfer instruction (VMOV) passing something via memory is suboptimal...
Additionally memory coherence mechanism must engage if stores to the same memory region occur close to each other - so this should be no problem for most SIMD algorithms, since they tend to work on large chunks of data.

Regardless of my above statements - it's a fact that we should have in mind when optimizing code. It's in no way a big problem (IMHO).

 

[mali]

Or perhaps the info can be placed in the Pandora wiki, which is stickied to this forum. If we can stick with one stickied post, it would be much better IMO.

I know, that the info is in the FAQ, but it takes four clicks to get to this particular link. I thought of a thread, where mainly the problems are mentioned and where people can post examples for ASM for different functions. For the whiz it's obvious where the problems are. But for others, who just want to spend the time on other things, it would be good if there was an easily understandable summary of what to do, if they need a somewhat acceptable FP performance, which they just don't get with VFP. It would be a timesaver IMO. Sometimes it's better to have some kind of notepad with directly available info than having to click through various link trees. I'm no dev, so maybe I'm wrong on this, though.

Edit:
Something I didn't find in the FAQ it describes the CPU pipeline, according to BeagleB IRC, this info isn't present in the TRM:
http://www.arm.com/pdfs/TigerWhitepaperFinal.pdf

 

[ldesnogu]

And since NEON has a ARM to NEON register transfer instruction (VMOV) passing something via memory is suboptimal...

OTOH, NEON to ARM transfer is at least 20 cycles so you don't want it

 

[mali]

OTOH, NEON to ARM transfer is at least 20 cycles so you don't want it

That's the whiz info I'm talking about
Edit:
http://www.gp32x.de/board/index.php?s=&am...st&p=681189
The most important part, I think:

... so if you have some arm code to run, clever interleaving with neon instructions lets both execute at the same time ...
... to get maximum performance from neon, you need to use the full register width and avoid neon to arm register transfers ...

 

[maciek_urbanski]

And since NEON has a ARM to NEON register transfer instruction (VMOV) passing something via memory is suboptimal...

OTOH, NEON to ARM transfer is at least 20 cycles so you don't want it

Ouch ! So it leaves us only with very conscious code layout when passing values from NEON to ARM (via memory)...

 

[Svartalf]

Ouch ! So it leaves us only with very conscious code layout when passing values from NEON to ARM (via memory)...

Yep. It's why I'd posted the link like I did. Sorry gang, I didn't catch that this little gem had propagated over to the Wiki, etc. I'd checked even...

 

[Squidge]

I know, that the info is in the FAQ, but it takes four clicks to get to this particular link. I thought of a thread, where mainly the problems are mentioned and where people can post examples for ASM for different functions. For the whiz it's obvious where the problems are. But for others, who just want to spend the time on
I think it would be best for everything to be in one place. We don't want some info on the forums, and other info on the Wiki. Also, we don't want information on the Wiki duplicated on the forums when a link will do. Am I correct in thinking anyone with an account car update the Wiki (edit and create new pages) ?

If you want to propose a new sticky to replace the current one which just links to the Wiki, then thats fine.

 

[mali]

You are of course right Duplicating things doesn't make sense. I just don't know how someone could add those little helpful snippets for example mru posts on IRC in a useful way. But nevermind, things will work out, I think.

 

[darkblu]

Regardless of my above statements - it's a fact that we should have in mind when optimizing code. It's in no way a big problem (IMHO).

i'd agree that it is not a big deal, as it's counterable on a higher/algorithmic level. the only problem i see is for auto-vectorized code ported over from architectures not suffering so severely from such a synchronization model.

 

[Yamara]

It makes sense to suss things out on the forum, then add the final conclusion to the Pandora wiki on a "NEON programming tips" page. Then you get the best of both worlds. The forum discussion can always be linked from the wiki if more detailed explanation would be useful.

@Squidge: You just need a login account to create/change on the Pandora wiki. The response was pretty fast when I signed up.

 

[Phawx]

Reading those logs, is NEON supposed to be handled like a one way street?

 

[mali]

Seing that TrevorBradley is running into problems with FP too, I'll just post this here to help keeping the NEON discussion going:
http://www.beagleboard.org/irclogs/index.p...01-07#T20:47:09

 

[TrevorBradley]

Seing that TrevorBradley is running into problems with FP too, I'll just post this here to help keeping the NEON discussion going:
http://www.beagleboard.org/irclogs/index.p...01-07#T20:47:09



Eaaggh... I can handle feeding the NEON fp data and then pulling it out many cycles later.. but I still need to pull it out at some point.

I'd like to get on top of this sooner rather than later. I am a bit of a clueless newb when it comes to customizing my code to the console's architecture. Is there some demo code for FP math using NEON/A8 out there somewhere? I'd like to know what I'm getting into.

Almost all the FP math I'm doing is the addition of vectors with float x,y value pairs, multiplication of vectors with scalars, and a lot of trig conversion of polar to cartesian co-ordinates: ((r,theta) -> (x,y)). Basically a whole whack of very simple floating point math. (There's a good chunk of psuedo-"random" number generation as well, but that's integer math.)

Thankfully most of that math is done in just two functions, so coming up with an alternate mechanism for generating 10,000+ stars on the screen at once may only mean re-writing a few blocks of code (crosses fingers, knocks on wood, slaughters goat for good measure)

 

[Yod4z]

it seems that mru for the beagleboard has done something for the ffmpeg in NEON
http://git.ffmpeg.org/?p=ffmpeg;a=tree;f=l...e4be7ff;hb=HEAD
the ones with neon in the name

 

[ldesnogu]

Eaaggh... I can handle feeding the NEON fp data and then pulling it out many cycles later.. but I still need to pull it out at some point.

You shouldn't be concerned; the performance issue Mans describes occurs when you have to exchange data through registers between NEON and ARM. That shouldn't happen that often, or that means your code is not a good candidate for NEON
QUOTE
I'd like to get on top of this sooner rather than later. I am a bit of a clueless newb when it comes to customizing my code to the console's architecture. Is there some demo code for FP math using NEON/A8 out there somewhere? I'd like to know what I'm getting into.

Mans' NEON FFmpeg is a good thing to look at. Look in FFmpeg svn under libavcodec/armv4l.
QUOTE
Almost all the FP math I'm doing is the addition of vectors with float x,y value pairs, multiplication of vectors with scalars, and a lot of trig conversion of polar to cartesian co-ordinates: ((r,theta) -> (x,y)). Basically a whole whack of very simple floating point math. (There's a good chunk of psuedo-"random" number generation as well, but that's integer math.)

Thankfully most of that math is done in just two functions, so coming up with an alternate mechanism for generating 10,000+ stars on the screen at once may only mean re-writing a few blocks of code (crosses fingers, knocks on wood, slaughters goat for good measure)

That seems to be perfect job for NEON: no interaction with ARM integer pipeline, stream of vectors as input and output. I'm sure you'll have fun with it, if you like assembly

 

[TrevorBradley]

Eaaggh... I can handle feeding the
Thankfully most of that math is done in just two functions, so coming up with an alternate mechanism for generating 10,000+ stars on the screen at once may only mean re-writing a few blocks of code (crosses fingers, knocks on wood, slaughters goat for good measure)

That seems to be perfect job for NEON: no interaction with ARM integer pipeline, stream of vectors as input and output. I'm sure you'll have fun with it, if you like assembly

That's actually a relief. I can deal with assembly, it's really not that much code (it's just looped over and over again). Especially if we can put it into libraries (which perhaps I'll release if I get working!) (I'll still need that slaughtered goat though).

I'll have a look at FFmpeg's svn, though I get the sense I won't get an intuitive understanding of the thing until I actually get to try it out for myself.
(Oh look, I just so happen to already have an svn of ffmpeg on my machine! Pretty old though... "svn up"!

Ahh, look at all those .S files...

(does a bit of googling)

I assume this page on ARM's documentation site will be a useful reference...

Gimme some time to distill this down to the 1.1+1.1=2.2 version...