[cairo] pixman: New ARM NEON optimizations

[Jonathan Morton]

On Tue, 2009-10-27 at 15:23 +0100, Koen Kooi wrote:
> > Something to be aware of, however, is that A9 can't issue a VFP instruction until the previous
> > NEON instruction has cleared out of the pipeline (and vice-versa), so interleaving NEON and VFP
> > really hurts on A9 but didn't really make a huge difference on A8.
> 
> I guess that's where the confusing stems from. Let's hope google indexes 
> this thread so the truth will surface :)

It's also a potentially significant difference from PowerPC's Altivec
(or VMX).  The PPC G4 and G5 have scalar FPUs that are totally separate
from the vector unit, allowing potentially 5 or 6 single-precision FLOPS
per cycle if you really push hard.  This is helped by the triple and
quadruple issue front-ends, which allow some memory and control traffic
in addition to full FP throughput.

On ARMv7-A, the "scalar" FPU is aliased into the NEON registers (and
possibly other hardware), which is probably why the A9 requires the
pipeline flush when switching between the two.  It's still worthwhile to
run integer control logic "behind" the vector computation though, and
double-issue is good enough for that.

Of course, we're not doing heavy FP in Pixman...

Another trick about the A9 I found by scraping the public docs: the A9
has a wide and flexible dispatch logic (each execution unit can pull an
instruction from the queue), but can only decode 2 instructions per
cycle (which then join the dispatch queue).

So for most purposes you should treat it as being dual-issue like an A8,
but with far fewer rules about which instructions can go together, and
less worry about precise latencies - obviously you can still be held up
by saturating an execution unit.  I can't tell whether it is able to
fold a branch in addition to the two full decodes, but if you optimise
for A8 that doesn't matter.

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com