Pandora, Some Actual Performance Numbers ..

[notaz]

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).

Yeah. Maybe I miscompiled something, do you still have the binaries you ran on N800? They should run on pandora too.

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

I think so. My flags:
-s -static -Wall -O3 -fomit-frame-pointer -funroll-loops -march=armv7a -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp
I've tried -ffast-math, but it makes little difference.

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

You mean with -ftree-vectorize?

 

[ldesnogu]

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).

Doesn't that only mean a program running on the Cortex-A8 non pipelined VFP @500 MHz is about the same speed as a pipelined VFP @330 MHz (assuming 1136 VFP is pipelined)?

 

[lardman]

QUOTE
-mfpu=neon


Ah, so your figures are for a build with neon enabled rather than vfp, that makes more sense now.

I'm just building an nbench binary (and glibc for libm) which I'll test on my N810 (OMAP2420 @400MHz) then give you a link. It is compliled with -mfpu=vfp so I presume it will like doubles better that way than the neon build with -mfpu=neon.

 

[lardman]

(vfp nbench, vfp libm)

CODE
Nokia-N810-23-14:/home/user# ./nbench.vfp

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 147 : 3.77 : 1.24
STRING SORT : 17.077 : 7.63 : 1.18
BITFIELD : 4.0275e+07 : 6.91 : 1.44
FP EMULATION : 16.653 : 7.99 : 1.84
FOURIER : 1251.6 : 1.42 : 0.80
ASSIGNMENT : 1.2622 : 4.80 : 1.25
IDEA : 352.25 : 5.39 : 1.60
HUFFMAN : 149.14 : 4.14 : 1.32
NEURAL NET : 1.4389 : 2.31 : 0.97
LU DECOMPOSITION : 48.442 : 2.51 : 1.81
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 5.587
FLOATING-POINT INDEX: 2.021
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU :
L2 Cache :
OS : Linux 2.6.21-omap1
C compiler : gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)
libc : ld-2.5.so
MEMORY INDEX : 1.285
INTEGER INDEX : 1.482
FLOATING-POINT INDEX: 1.121
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.


(soft-float nbench, vfp libm)

CODE
Nokia-N810-23-14:/home/user# ./nbench.soft-float

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 147.72 : 3.79 : 1.24
STRING SORT : 17.123 : 7.65 : 1.18
BITFIELD : 4.0327e+07 : 6.92 : 1.44
FP EMULATION : 16.587 : 7.96 : 1.84
FOURIER : 970.92 : 1.10 : 0.62
ASSIGNMENT : 1.2654 : 4.81 : 1.25
IDEA : 352.53 : 5.39 : 1.60
HUFFMAN : 130.6 : 3.62 : 1.16
NEURAL NET : 0.21155 : 0.34 : 0.14
LU DECOMPOSITION : 5.7335 : 0.30 : 0.21
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 5.489
FLOATING-POINT INDEX: 0.481
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU :
L2 Cache :
OS : Linux 2.6.21-omap1
C compiler : gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)
libc : ld-2.5.so
MEMORY INDEX : 1.288
INTEGER INDEX : 1.434
FLOATING-POINT INDEX: 0.267
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.


Files are here: http://people.bath.ac.uk/enpsgp/benchmarks/new/

 

[notaz]

QUOTE
-mfpu=neon

Ah, so your figures are for a build with neon enabled rather than vfp, that makes more sense now.

I think neon in this case means (neon+vfp), as this emits VFP instructions and no neon. If I enable -ftree-vectorize, it starts emitting neon instructions too. However, it doesn't emit any neon instruction for nbench, but if I somewhere paste code like this, the neon instructions start appearing

 

[lardman]

The wonders of GCC naming conventions

 

[Phawx]

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).


Nevermind on the geforce 6600 stuff. Instead of trying to fudge numbers together, I decided to look if the 530 has been in any other product that has been tested. It would seem the SGX 535 is the Intel GMA 500. The SGX 530 seems to push half as much as the 535.

Certainly it will be interesting to see what the choir of chips are capable of doing. Between ARM/DSP/SGX handeling AI/Physics/Rendering, not respectively. Just from the SGX we are looking at something that should be as good as the flipper chip in the Gamecube, maybe a little better. Get the DSP chip to crunch the physics and the ARM for sound (figure the DSP would be better off doing physics than the ARM, no?) AI and just overseeing everything else running in the system.

Also the amount of RAM that we have now is interesting as well. If someone could make physics work well and we could store a nice set of textures to work with, I would imagine we could see some pretty impressive stuff from the Pandora with it's 800x480 screen.

 

[notaz]

[root@pandora nbench_lardman]# ./nbench.vfp
CODE

TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 251.76 : 6.46 : 2.12
STRING SORT : 29.261 : 13.07 : 2.02
BITFIELD : 9.2174e+07 : 15.81 : 3.30
FP EMULATION : 33.387 : 16.02 : 3.70
FOURIER : 846.48 : 0.96 : 0.54
ASSIGNMENT : 2.7216 : 10.36 : 2.69
IDEA : 567.29 : 8.68 : 2.58
HUFFMAN : 234.1 : 6.49 : 2.07
NEURAL NET : 0.98619 : 1.58 : 0.67
LU DECOMPOSITION : 38.578 : 2.00 : 1.44
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 10.321
FLOATING-POINT INDEX: 1.450
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 : gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)
libc : ld-2.5.so
MEMORY INDEX : 2.618
INTEGER INDEX : 2.544
FLOATING-POINT INDEX: 0.804



[root@pandora nbench_lardman]# ./nbench.soft-float
CODE

TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 252.24 : 6.47 : 2.12
STRING SORT : 29.29 : 13.09 : 2.03
BITFIELD : 9.2084e+07 : 15.80 : 3.30
FP EMULATION : 33.027 : 15.85 : 3.66
FOURIER : 779.78 : 0.89 : 0.50
ASSIGNMENT : 2.7206 : 10.35 : 2.69
IDEA : 567.07 : 8.67 : 2.58
HUFFMAN : 218.08 : 6.05 : 1.93
NEURAL NET : 0.30989 : 0.50 : 0.21
LU DECOMPOSITION : 8.4317 : 0.44 : 0.32
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 10.203
FLOATING-POINT INDEX: 0.578
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 : gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)
libc : ld-2.5.so
MEMORY INDEX : 2.618
INTEGER INDEX : 2.493
FLOATING-POINT INDEX: 0.320



It seems CodeSourcery 2007q3 does better code, my compiled versions are a bit faster

 

[notaz]

Just for fun, I've hacked nbench and replaced all double variables + math calls to floats, and got this:
CODE

TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 199.36 : 5.11 : 1.68
STRING SORT : 29.062 : 12.99 : 2.01
BITFIELD : 9.5893e+07 : 16.45 : 3.44
FP EMULATION : 55.738 : 26.75 : 6.17
FOURIER : 639.51 : 0.73 : 0.41
ASSIGNMENT : 4.0447 : 15.39 : 3.99
IDEA : 568.18 : 8.69 : 2.58
HUFFMAN : 298.92 : 8.29 : 2.65
NEURAL NET : 1.1512 : 1.85 : 0.78
LU DECOMPOSITION : 47.8 : 2.48 : 1.79
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 11.828
FLOATING-POINT INDEX: 1.493
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.021
INTEGER INDEX : 2.900
FLOATING-POINT INDEX: 0.828



Now, if I set FPSCR to 0x03000000 on startup (RunFast mode?), I get this:
CODE

: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 196 : 5.03 : 1.65
STRING SORT : 29.147 : 13.02 : 2.02
BITFIELD : 9.5751e+07 : 16.42 : 3.43
FP EMULATION : 55.653 : 26.71 : 6.16
FOURIER : 891.16 : 1.01 : 0.57
ASSIGNMENT : 4.0431 : 15.38 : 3.99
IDEA : 567.74 : 8.68 : 2.58
HUFFMAN : 306.98 : 8.51 : 2.72
NEURAL NET : 1.5582 : 2.50 : 1.05
LU DECOMPOSITION : 76.6 : 3.97 : 2.87
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 11.842
FLOATING-POINT INDEX: 2.159
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.022
INTEGER INDEX : 2.906
FLOATING-POINT INDEX: 1.198


Note that changing FPSCR had no effect before double->float conversion. Don't know why FOURIER went down after conversion though.

 

[nikkopt]

SGX 530 poly count at 200MHz: 13.5M/sec
nVidia geforce 256 poly count at 120MHz: ~12M/sec
nVidia geforce 2 ultra poly count at 250MHz: >19M/sec
nvidia geforce fx 5200 poly count at 250MHz: ~30M/sec

don't expect a 6600 like performance

anyway.. SGX 530 fillrate is pretty awesome and the geforce 256 itself was an amazing card (more than 100 fps on quake 3 in high quality)

 

[Prophet]

Sorry to interrupt all the technical banter...

...but wow, those numbers were nice to see. Thanks Jeff! I didn't expect it to be so much faster than those other devices, especially the Wiz at similar clock speeds. TI clearly did a good design job.

I still need to place my reorder. I think my refund must be processed by now. Will check tonight when I get home.

 

[Adventus]

QUOTE
Now, if I set FPSCR to 0x03000000 on startup (RunFast mode?)
Assuming its actually being set, that should enable runfast mode (sets bits 24-25 and sets exceptions bits to 0). I presume you've already set the VFP + NEON (cp10 and cp11) to secure privileged mode?

These results are confusing. It might be best if we ask if anyone with a beagle board has run nbench with the Neon enabled?

QUOTE
SGX 530 poly count at 200MHz: 13.5M/sec
nVidia geforce 256 poly count at 120MHz: ~12M/sec
nVidia geforce 2 ultra poly count at 250MHz: >19M/sec
nvidia geforce fx 5200 poly count at 250MHz: ~30M/sec
These numbers are pretty meaningless, the architecture difference are vast. Check the other GPU performance threads for a lengthy discussion.

 

[Phawx]

SGX 530 poly count at 200MHz: 13.5M/sec
nVidia geforce 256 poly count at 120MHz: ~12M/sec
nVidia geforce 2 ultra poly count at 250MHz: >19M/sec
nvidia geforce fx 5200 poly count at 250MHz: ~30M/sec

don't expect a 6600 like performance

anyway.. SGX 530 fillrate is pretty awesome and the geforce 256 itself was an amazing card (more than 100 fps on quake 3 in high quality)

Yea I corrected myself a couple of posts up. To be fair, the SGX 530 pushes the same amount of polys as the gamecube and has a fillrate that crushes the NV2A in the Xbox. The Gamecube has double the memory throughput, Pandora's being ~1.3GB/s, but we also have all of the efficiencies of the PowerVR architecture that compensate for memory throughput to have T&L and 2-4xAA enabled for close to free. On top of everything we have a feature set capable of supporting geometry instancing and displaced subdivision surfaces (great thread on the other board). And even on top of THAT is that the SGX 530 is stupidly power efficient. I.E. Compartmentalizing the 2D engine from the 3D engine to save power when not using the 3D engine. Oh, I forgot to mention that we have 256 MBs of RAM. That's 4x the amount of the original Xbox. Obviously we still need to store the OS in that, but we still have a ton of RAM compared to the last generation of consoles.

Clearly, the SGX 530 walks a VERY fine line. From reading the other thread, you can see the lengths ImgTec has gone to minimize it's weaknesses and keeping CPU and memory system bandwidth load way down. The design decisions for each of the components with the Cortex A8 seem to coalesce into some magnificent beast. In all seriousness, Pandora's whole is greater than the sum of its parts. It's hard to definitively compare the Pandora to anything else. We can try to separate its parts and scrutinize them, but I have a gut feeling, when we see the Pandora as a whole hit 88 miles an hour, we're gonna see some serious shit.

 

[Vorporeal]

Totally agree with the above. Each component has been, by itself, extremely impressive. When we combine all of these together, we will end up with the closest possible thing to the "ultimate device". ULTRA-portable, very powerful, with lots of room for connectivity and expansion. What more could you ask for?

 

[Bosbeetle]

Totally agree with the above. Each component has been, by itself, extremely impressive. When we combine all of these together, we will end up with the closest possible thing to the "ultimate device". ULTRA-portable, very powerful, with lots of room for connectivity and expansion. What more could you ask for?

It just needs a little bit more cowbel

 

[Vorporeal]

Totally agree with the above. Each component has been, by itself, extremely impressive. When we combine all of these together, we will end up with the closest possible thing to the "ultimate device". ULTRA-portable, very powerful, with lots of room for connectivity and expansion. What more could you ask for?

It just needs a little bit more cowbel


:lol:

 

[MDave]

Totally agree with the above. Each component has been, by itself, extremely impressive. When we combine all of these together, we will end up with the closest possible thing to the "ultimate device". ULTRA-portable, very powerful, with lots of room for connectivity and expansion. What more could you ask for?

Hold on a cotten-picking second here!

How's that saying go? "You're only as strong as your weakest link."

What I mean to say is, there could be a bottle neck somewhere that could really throw a wrench into the works in terms of theoretical peak performance from the sum of all it's parts.

 

[Phawx]

Totally agree with the above. Each component has been, by itself, extremely impressive. When we combine all of these together, we will end up with the closest possible thing to the "ultimate device". ULTRA-portable, very powerful, with lots of room for connectivity and expansion. What more could you ask for?

Hold on a cotten-picking second here!

How's that saying go? "You're only as strong as your weakest link."

What I mean to say is, there could be a bottle neck somewhere that could really throw a wrench into the works in terms of theoretical peak performance from the sum of all it's parts.


I don't know, almost none of the numbers from PowerVR are ever theoretical, even from the Kyro II days. Dreamcast games are a great example of image quality over what they were pushing. Looking over the SGX 530, you can see they made it to be largely independent from other systems.

I am looking at the diagram of the OMAP 3530 right now and that L3 interconnect might be a problem keeping everything fed properly. The proof will be in the pudding, but I truly believe the Cortex A8 system has been designed in such a way to have every subsystem act on its own. Sort of like a mini Justice League. Each of these chips can be made to perform a general function, but you can choose which function should be working where to minimize power draw while still completing the function with the desired effect. Truly when the software is worked out, gaming will eke out every last oz of power from the machine.

I would like to see a physics demo running off of the DSP.

 

[nikkopt]

SGX 530 poly count at 200MHz: 13.5M/sec
nVidia geforce 256 poly count at 120MHz: ~12M/sec
nVidia geforce 2 ultra poly count at 250MHz: >19M/sec
nvidia geforce fx 5200 poly count at 250MHz: ~30M/sec

don't expect a 6600 like performance

anyway.. SGX 530 fillrate is pretty awesome and the geforce 256 itself was an amazing card (more than 100 fps on quake 3 in high quality)

Yea I corrected myself a couple of posts up.


yeah, i wasn't flaming

 

[cb88]

although the fill rate is comparable i think you will find the SGX to be more powerfull than the geforce considering is actually has shaders instead of NSRs which i was told on #nouveou are just register combiners... and arn't programable