Pandora, Some Actual Performance Numbers ..


lardman said:
Here are some comparison figures for the pure benchmark app nbench. Would be interesting to see how the Pandora/OMAP3 stacks up against these (especially as there's an OMAP1 and 2 in there).

http://wiki.hbmobile.org/index.php?title=A...ssor_Benchmarks

P.S. You'll need a vfp/neon compiled libm too


I tried this today. I guess I don't have everything on my card needed to run the test all the way through but at 600MHz these are the results I got (and it stops here at any speed):
CODE
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 246.24 : 6.31 : 2.07
STRING SORT : 33.986 : 15.19 : 2.35
BITFIELD : 9.0931e+07 : 15.60 : 3.26
FP EMULATION : 62.046 : 29.77 : 6.87
FOURIER : 270.59 : 0.31 : 0.17


Notaz did a 900MHz test months ago (on a much older kernel, 2.6.22 I think). He knows more about making sure all dependencies are met than I do. I will post his results. I hope he doesn't mind but it fits this topic well:
CODE

TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 363.48 : 9.32 : 3.06
STRING SORT : 49.96 : 22.32 : 3.46
BITFIELD : 1.3284e+08 : 22.79 : 4.76
FP EMULATION : 91.527 : 43.92 : 10.13
FOURIER : 395.63 : 0.45 : 0.25
ASSIGNMENT : 5.8503 : 22.26 : 5.77
IDEA : 982.24 : 15.02 : 4.46
HUFFMAN : 604.53 : 16.76 : 5.35
NEURAL NET : 1.1844 : 1.90 : 0.80
LU DECOMPOSITION : 66.92 : 3.47 : 2.50
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 19.739
FLOATING-POINT INDEX: 1.437
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
MEMORY INDEX : 4.562
INTEGER INDEX : 5.217
FLOATING-POINT INDEX: 0.797
 
Last edited by a moderator:
The floating point index seems a bit low, is it using doubles? Or without Neon?

Relative to the OMAP2, The integer and memory results are impressive.

According to this result table, the INT & MEM are about equivalent to a PIII @ 1Ghz + 133Mhz SDRAM.
 
Adventus said:
The floating point index seems a bit low, is it using doubles? Or without Neon?

Relative to the OMAP2, The integer and memory results are impressive.

According to this result table, the INT & MEM are about equivalent to a PIII @ 1Ghz + 133Mhz SDRAM.



Looks like its running without Neon. Those results are a bit to bad.

Yea, those Memory and Integer results at 900Mhz, are about equal to the PIII at 933Mhz

CODE

MEM INT
Pentium III (Coppermine) 933MHz 256 KB 4.587 5.374
Pandora 900Mhz 4.562 5.217



So those dhrystone MIPS results we have been using in the past seems to be backed up. The 1200 dhrystone MIPS @ 600Mhz -> 1800 dhrystone MIPS @ 900Mhz = PIII @ 900Mhz.

In other words, its we can say its a PIII in your pocket ;) Ofcourse, thats not taking in account the possible extra's gained from the NEON, DSP, And 3D ( when there are drivers ;) ) if used properly.
 
Last edited by a moderator:
I thought I was using NEON, but who knows. I added the flags Gnostic recommended:

-O3 -fomit-frame-pointer -mfloat-abi=softfp -mfpu=neon -mcpu=cortex-a8 -ftree-vectorize -ffast-math

I was using Code Sourcery q3-2007 as I hear the 2008 version will mess me up good. :) Some programs I have tried to build with q1-2008 would fail and never even build in the first place. These build options only apply to my 600MHz test. I don't know what Notaz's 900MHz setup was but his 500MHz results were pretty much exact to my 500MHz test results.

To be fair, the 500MHz results were still better than the i.MX31 which has a proper floating point unit (right?). These were my results at 500MHz:
CODE
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 205.52 : 5.27 : 1.73
STRING SORT : 28.303 : 12.65 : 1.96
BITFIELD : 7.5325e+07 : 12.92 : 2.70
FP EMULATION : 51.738 : 24.83 : 5.73
FOURIER : 225.28 : 0.26 : 0.14


Someone more knowledgeable on the bugs and workings of the available compilers could probably suggest what could be done to improve the results. Laurent?

I don't know if mru from the Beagleboard chatrooms ever visits here, but he could tell me more about the suckage of some compiler versions. :p
 
I would guess that runfast mode isn't enabled. It details how to enable it Here. However, from what i read, the flags you've set should enable runfast mode.... so maybe the compilers at fault.

Maybe the code to manually enable runfast mode might help:CODE
AREA RunFast, CODE, READONLY

VFPEnable EQU 0x40000000

RF_Enable EQU 2_11:SHL:24
; Bit pattern to enable RunFast mode
; FPSCR [24] - Flush to Zero mode
; FPSCR [25] - Default NaN mode

EXPORT RunFast_Enable

RunFast_Enable FUNCTION
MOV r0,#RF_Enable
FMXR FPSCR, r0 ; FPSCR = r0
BX LR
ENDFUNC

EXPORT Enable_VFP

Enable_VFP FUNCTION
; Enable VFP itself
MOV r0,#VFPEnable
FMXR FPEXC, r0 ; FPEXC = r0
BX LR
ENDFUNC

END
 
Laurent said:
Alas currently gcc does not support -mfloat-abi=hard which could bring some speedup when passing floats to functions.

As far as performance goes, I would say the speedup comes from larger L1 cache, the existence of an L2 cache and faster RAM. Basically the memory subsystem is better.

Skeezix: And for graphics complexity of the ST I agree, though I expect to see how Outcast handles hardware scrolling and border removal demos :) Also I'd be interested to see profiling results...
Larger L1 cache? All the platforms have 16/16KB L1, unless TI has been lying to us for some strange reason.
 
Last edited by a moderator:
The other reason why the OMAP2 might be faster is that it was compiled with vfp. If the test uses doubles this will make a huge difference as afaik Neon only accelerates singles. (just to expand on Adventus' comment about doubles :))

QUOTE
So those dhrystone MIPS results we have been using in the past


Here are the dhrystone/whetstone results for the OMAP1/2 (770/N800) for comparison:

http://people.bath.ac.uk/enpsgp/benchmarks/
 
Exophase said:
Laurent said:
Alas currently gcc does not support -mfloat-abi=hard which could bring some speedup when passing floats to functions.

As far as performance goes, I would say the speedup comes from larger L1 cache, the existence of an L2 cache and faster RAM. Basically the memory subsystem is better.

Skeezix: And for graphics complexity of the ST I agree, though I expect to see how Outcast handles hardware scrolling and border removal demos :) Also I'd be interested to see profiling results...
Larger L1 cache? All the platforms have 16/16KB L1, unless TI has been lying to us for some strange reason.

My bad, I was thinking of the cache starved 940T :) Anyway the L2 cache makes a huge difference, as was noticed on the Beagle when they enabled it u-boot.
 
Last edited by a moderator:
Has the floating point discrepancy been figured out, yet?
I've found some nbench numbers for Atom N270 and the results are quite interesting.
Performance per MHz is much better on Cortex A8(so performance per Watt is unbelievably high compared to Atom) except the low fp results. I would be very happy, if the people involved would shed some more light on it, please :)
 
I was just going to comment on the N270 and its relation to performance comparable to a P3 1Ghz. The N270 is 2.5w so the A8 is considerably more powerful in terms of power consumption/calculations.

I have an Asus N10 and I have to overclock my N270 from 1.6 to 2.1Ghz just to keep up with the Nvidia 9300m in my netbook.

I can't wait until we get some drivers for the SGX so that we can make some comparisons to other GPUs. Last I looked, just guess work, it was close to a Geforce 6600 I believe. But time will tell.

Either way, I am very excited.
 
This is very exciting, indeed :)
I'm a long-time handheld fan, but Pandora will shift performance and usability to a whole new level.
 
Hmmm, To test if the Neon is actually enabled maybe we should do the nbench without the mfpu flag?

Also i had a chat with mru on the beagleboard irc. He thinks runfast mode is not enabled and that the asm i posted previously should work.
 
It would be good to see, once and for all, a test bench that verifies a speed difference in transitioning between the non-run-fast and run-fast modes. Also to compare against NEON. The following tests might be useful:

- VFP code with dependency chain every instruction
- VFP code with dependencies broken up by integer code
- VFP code without dependencies for several instructions
- NEON versions of the above

With an without run-fast mode procedure. Would have to be written in ASM of course. I might see if I can get someone to run it for me.
 
Phawx said:
I can't wait until we get some drivers for the SGX so that we can make some comparisons to other GPUs. Last I looked, just guess work, it was close to a Geforce 6600 I believe. But time will tell.
Erm... I will be REALLY surprised if that is true.
All I read was is that teh SGX535 has 2 (TWO) pipelines. What kind of pipelines they mean is not clear to me. Lets assume it are 2 pipelines each can handle a quad of pixels, then the processing power is way lower than the 6600. However, the resolution is a BIT lower. I would be happy if the SGX is as fast as my 6200.

I am very interested in the GPU. So if anyone has more information concerning it he is very welcome to tell me :)


EDIT:
just had a peek at Wikipedia. The 6-Series has more pixelshader BUT it is only clocked at 200 to 300 MHz. Now assuming the SGX is clocked at 500MHz or more it MIGHT be possible that it is close to a slower 6600er.
Now I am getting excited too. Can some dev run a 3d benchmark? I can code something (plain triangles with textures, however, that might not be enuff).
 
Last edited by a moderator:
Adventus said:
Also i had a chat with mru on the beagleboard irc. He thinks runfast mode is not enabled and that the asm i posted previously should work.
I've tried clearing those bits, as the manual says, but that didn't affect benchmark results. We might need to disable VFP while this is done, I haven't done that because VFP was already enabled. This also probably depends on math lib being compiled with VFP, I just used whatever compiler links by default with those flags.

Exophase said:
It would be good to see, once and for all, a test bench that verifies a speed difference in transitioning between the non-run-fast and run-fast modes. Also to compare against NEON. The following tests might be useful:

- VFP code with dependency chain every instruction
- VFP code with dependencies broken up by integer code
- VFP code without dependencies for several instructions
- NEON versions of the above

With an without run-fast mode procedure. Would have to be written in ASM of course. I might see if I can get someone to run it for me.
If you have some code I'd be happy to run it for you.
 
Last edited by a moderator:
QUOTE
just had a peek at Wikipedia. The 6-Series has more pixelshader BUT it is only clocked at 200 to 300 MHz. Now assuming the SGX is clocked at 500MHz or more it MIGHT be possible that it is close to a slower 6600er.

IIRC it was mentioned, that SGX may run at 266MHz 133Mhz at SGX_L3_FCLK / 3 and a CPU coreclock of 200Mhz with a special clock multiplier combination but 500MHz is very unlikely to have a multiplier setting, and there would be serious stability/heat issues.

Edit2:
MWeston said:
If I remember correctly, the SGX core has two ways to set its clock. It can be set to a fixed frequency of 96MHz or it can be a divided down frequency of the CPU clock. The legal dividers are 3, 4, 5 and 6. It's been a while since I looked that up but I think it's right.

The demos we saw in Texas were running at 500MHz with the SGX core at 166MHz which means they were using a divider of 3. Based on that, you can speculate which values would work for 600, 800 and 900 MHz. :)
But notice the bolded part. In the SGX RE thread the highest number according to the docs was 133MHz

Edit3:
Exophase said:
Yeah, it's weird that it's not in the main doc. I honestly don't know what its information is about.
From OMAP35x Applications Processor 2D/3D Graphics Accelerator (SGX)
(http://www.ti.com/litv/pdf/spruff6b) page 10:

"SGX_FCLK is the functional clock and is used inside the SGX subsystem to generate SGX and 3D
domain clock signals.
The source of SGX_FCLK is either the PRCM clock (SGX_L3_FCLK, which is derived from
SGX_ICLK) or the peripheral DPLL clock DPLL4_M2X2_CLK as depicted in the SGX Power Domain
Clocking Scheme section of the Power, Reset, and Clock Management chapter. Selection is made at
the PRCM level by setting the PRCM.CM_CLKSEL_SGX[2:0] CLKSEL_SGX bit field. A divider of 3, 4,
or 6 is applied to the SGX_FCLK frequency with regard to the PRCM SGX_L3_FCLK frequency. By
default the SGX_FCLK clock is SGX_L3_FCLK / 3."

Unfortunately, it's really hard for me to dig up exact information on what the PRCM clock can be clocked to right now, maybe you can look over that more for me (this doc: http://www.ti.com/litv/pdf/sprufa5a) but as far as I'm aware it supplies the CPU clock directly. Either way, you can see that what I said about the dual clocks and divider is correct (although DPLL4_M2X2_CLK seems to be 96MHz, not 90MHz)
blu said:
on the clocks subject:
i too seem to remember reading in some specs what Exophase has quoted here (MWeston's post), but when i tried to retrace the source, i came across the omap3530 (preliminary) datasheet (i believe already linked in this thread) which is clear on the subject (p.146, table 4-17, DPLL3 Clock Frequency Ranges, VDD2 OPP3):

SGX (running off the DPLL3 loop) is rated at 110.67MHz @ OPP3 (nominal), where 3530's OPPs go up to 5 - 'overdrive' (OPP4 being 'mid-overdrive').

now, re OPP5, the datasheet does not provide numbers for DPLL3, but judging from the OPP5/OPP3 overdrive ratio for DPLL1 & 2, namely, 6/5, we could conclude that DPLL3 goes up to 6/5 * 664 = 797MHz, and SGX, up to 133MHz, respectively. which agrees wih what maciek suggested earlier.
 
Last edited by a moderator:
QUOTE
This also probably depends on math lib being compiled with VFP, I just used whatever compiler links by default with those flags.


Ah yes, for the results I posted above I compiled glibc with vfp support and then used LD_LIBRARY_PATH to use the new libm.

I initially forgot to do this so there are also some results with the vfp compiled nbench + non-vfp compiled libm. This might be what's happened here with the Pandora, and the difference is pretty big for the FOURIER and NEURAL NET results.

Results without vfp libm: http://lists.openmoko.org/pipermail/commun...uly/006382.html

Results with vfp libm: http://lists.openmoko.org/pipermail/commun...uly/006460.html

Cheers,


Simon
 
ok I've compiled libm with vfp, here are the results (@500MHz):

CODE

TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 195.44 : 5.01 : 1.65
STRING SORT : 29.809 : 13.32 : 2.06
BITFIELD : 9.5261e+07 : 16.34 : 3.41
FP EMULATION : 55.671 : 26.71 : 6.16
FOURIER : 915.66 : 1.04 : 0.58
ASSIGNMENT : 4 : 15.22 : 3.95
IDEA : 567.74 : 8.68 : 2.58
HUFFMAN : 298.69 : 8.28 : 2.64
NEURAL NET : 1.0435 : 1.68 : 0.71
LU DECOMPOSITION : 41.35 : 2.14 : 1.55
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 11.802
FLOATING-POINT INDEX: 1.552
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU :
L2 Cache :
OS : Linux 2.6.27-omap1-00039-gd33dca8-dirty
C compiler : arm-none-linux-gnueabi-gcc
libc : static
MEMORY INDEX : 3.029
INTEGER INDEX : 2.884
FLOATING-POINT INDEX: 0.861



I've tried triggering RunFast again by setting FPSCR to 0x03000000, but that didn't affect results at all. Might be because float test mostly uses doubles.
 
Curious, the FOURIER and NEURAL NET scores are still about the same as (in fact a little less than) the benchmark running on an OMAP2420 (N800) @330MHz (compiled with vfp).

I take it these are the results with nbench compiled for vfp as well?

What happens if you compile libm (and nbench) for Neon?
 
Back
Top