fusion_power said:
I guess it's because the GP2X has not even half the MHz of the Pandora? ^^ Or was the Test with equal clock Speed? I would like to know the per-MHz power of the Pandora compared to the one from GP2X. Can make the Pandora more out of one MHz than hte GP2X could? (weird comparing I know, but for me as a average User it could help to see how fast the Pandora really is, when the higher clocking is ignored
)
It isn't that simple. If the application is purely computationally bound and cache resident then it'll usually perform better per clock than GP2X. If it's purely memory bound then its performance will be more dictated by Pandora's memory bus, which is not clocked synchronously with the CPU like it is on GP2X. Most real applications are somewhere between the two.
In terms of raw write bandwidth Pandora has more than twice GP2X has - at stock clock speeds, 166MHz DDR vs 100MHz SDR, it's about 3.33x. Unfortunately, memory write tests show that you only get some fraction of this; you get the most if you use NEON, (and for memory to memory copies it pays to use the cache preload engine). The problem is probably with how L2 cache is working. From what I understand L2 is normally being configured as write allocating, although it can be configured as write-through and this can be done differently for different memory regions. This means that every write has to go through L2 cache and causes a miss, which has overhead of several cycles. What's worse if you have writes which are not clearing the entire cache line (either through bursts or possible write combining on the write buffer), because then they have to be merged with reading in the non-modified parts from memory. This is probably why NEON code tends to run better, because it's easier to get it to burst whole cache lines.
So you can see, with standard C code performing blits to normal L2 cached memory.. this isn't going to be 100% memory bandwidth limited, but getting twice the performance is still pretty good.
When writing straight to the framebuffer you don't go through L2 cache, so you don't have these problems. But if you want to do alpha blending you would prefer for the framebuffer to be cached if it'll fit (320x240x16bpp will). If you compare SDL alpha blending performance between GP2X and Pandora I bet Pandora has much more of an advantage. For alpha blending the best choice is probably memory allocated configured w/o L2 write allocation.. maybe this can be an option in ofbset or something.
One other thing: even w/o caching interfering you still can't get full bandwidth because some is being used for drawing the screen. This is the case for GP2X too, but it only has 320x240 vs 800x480 on the Pandora, which I think will only go away if you completely turn off the non-overlay DSS layer and use the overlaid ones scaled (actually, ofbset /dev/fb0 -en 0 might work, but also cause terrible things to happen if you don't turn it back on afterwards? Need to try this later)
