Graphics Speed

[BlackCardinal]

I am thinking about replacing my old 5500 with a newer clamshell model, probably the C1000.  I am a little concerned about the graphics speed, though, since I know that Sharp used the integrated LCD controller of the PXA270 instead of the W100 like on previous models.  I've searched the forum and found a lot of discussion about the graphics hardware but no comparisons between, say, a C760 and a C1000 for playing games.

Can any people who've owned more than one clamshell model comment on how fast the C1000 (or C3K or C3100) seems graphics-wise compared to their older Zaurus?  I am mostly concerned about video playback and games like Doom or the SNES emulator.

Would I be better off buying a C860 if graphics speed is important to me?

[Cresho]

look for my snes and nes emulator......also look for my video tutorial and packages.............100 percent full speed.

[lardman]

I'd also be interested in a side by side comparison of how fast the graphics are on the two different types.

Anyone have any figures? (there's a benchmark applet in OZ/Opie if anyone's running that on their PXA270 machine).


Si

[chiark]

I have both a 760 and a 1000 - if you can give me a hint on what to do to benchmark, then I'll run the tests.

The 1000 feels faster in use to me, especially when it comes to screen updates, but that doesn't answer your question!

I'm running Cacko 1.23beta on both of 'em.

[BlackCardinal]

Does PrBoom or some other SDL game have a framerate indicator that can be turned on?  I looked for one in PrBoom, but couldn't find one.

I suppose I could write a simple Qtopia graphics benchmark program, but I'm not sure that would be indicative of anything other than raw processor speed.  It's been about two years since I last wrote a Qtopia app, though, so my skills are a little rusty...  

An SDL-based benchmark would probably be more indicative of performance for video and games, anyway.  I'll see if I can find something that already exists that might work for a comparison.

[BlackCardinal]

Here's a couple of ideas for a video test.  I tried these on my 5500.

1.  Using MPlayer, play a video with these options from the command line:

Code: [Select]

$ mplayer -benchmark -framedrop -nosound some_short_video.mpgIf the video drops frames, then the FPS or dropped frame count can be used to compare.  If it doesn't then the Sys: parameter can be compared.  If one Z drops frames and the other doesn't, well that's interesting, too!

2.  Using VLC, play a video and analyze the output for dropped frames:

Code: [Select]

$ vlc -v --noaudio some_short_video.mpg 2>test.txt
$ grep -c skipped test.txtFor VLC, a video that is hard enough for the Z to drop frames is needed.  If both Z's can play the video without dropping frames, we don't learn anything!

Of course, a lot more than the graphics hardware is involved when playing back movies, but at least it's a "real-world" sort of test.

[BlackCardinal]

Well, I hate to reply to myself twice in a row, but this time I've put together a little SDL benchmark program that might be useful for this comparison.  It performs the following tests:

- point drawing, update screen every point
- point drawing, update every row of points
- filled rectangles
- bitblt of a 32x32 "sprite"

It runs the tests up to four times:  320x240 software, 320x240 hardware acceleration, 640x480 software, and 640x480 hardware acceleration.  It will only run those tests that are actually supported by the hardware & SDL library on the system.

To use, either install the binary (built for SDL v1.2 on ARM4) or you can build it yourself from the source code available at my website:  SDL benchmark on Gelhaus.Net.

If you're willing, please run these on your Z's and post the results.

For comparison, here's how my SL-5500 scored:

Code: [Select]

Pitch = 320
Hardware surfaces avail  = 0
Window manager avail     = 0
Blitter hardware         = 0
Colorkey blit hardware   = 0
Alpha blit hardware      = 0
Software->Hardware accel = 0
Video memory             = N/A

                          320x240  320x240  640x480  640x480
                          software hardware software hardware
Slow points (frames/sec): 0.260323    N/A      N/A      N/A  
Fast points (frames/sec):  20.4767    N/A      N/A      N/A  
    Rect fill (rects/sec):  416.472    N/A      N/A      N/A  
  32x32 blits (blits/sec):  625.535    N/A      N/A      N/A  
and, just for fun, here's my Windows laptop at work (2GHz Pentium 4 with Mobility Radeon 7500):

Code: [Select]

Pitch = 320
Hardware surfaces avail  = 1
Window manager avail     = 1
Blitter hardware         = 1
Colorkey blit hardware   = 1
Alpha blit hardware      = 0
Software->Hardware accel = 1
Video memory             = 32456

                          320x240  320x240  640x480  640x480
                          software hardware software hardware
Slow points (frames/sec):  7.44879     2000  2.95094  470.588
Fast points (frames/sec):  408.293  930.909  179.523   228.98
    Rect fill (rects/sec):  22382.5   163840  11160.8   146286
  32x32 blits (blits/sec):    32768   120471    37578   128000

[willgan]

I downloaded the source code and compile ...
My machine is C1000 running pdaxrom rc12..

Compiling with FLAGS = -03 -mcpu=xscale -mtune=xscale give me this result

Code: [Select]

itch = 320
Hardware surfaces avail  = 1
Window manager avail     = 0
Blitter hardware         = 0
Colorkey blit hardware   = 0
Alpha blit hardware      = 0
Software->Hardware accel = 0
Video memory             = 600

                          320x240  320x240  640x480  640x480
                          software hardware software hardware
Slow points (frames/sec): 0.387822 0.388387 0.0331474 0.0331628
Fast points (frames/sec):    40.22  40.2642  7.18375  7.18677
   Rect fill (rects/sec):  1971.13  1970.18  221.765  222.234
 32x32 blits (blits/sec):  5271.56  5285.16  4209.66  4209.66
But with flags = -03 -mcpu=iwmmxt -mtune=iwmmxt -march=iwmmxt , i get..

Code: [Select]

Pitch = 320
Hardware surfaces avail  = 1
Window manager avail     = 0
Blitter hardware         = 0
Colorkey blit hardware   = 0
Alpha blit hardware      = 0
Software->Hardware accel = 0
Video memory             = 600

                          320x240  320x240  640x480  640x480
                          software hardware software hardware
Slow points (frames/sec): -1.973e-130 3.50975e+107 5.43145e-113 -1.6179e+211
Fast points (frames/sec): 2.78013e+204 -8.30271e-155 2.20349e+206 -7.95162e-158
   Rect fill (rects/sec): -7.1062e+286 3.30822e-20 4.47658e+269 4.47658e+269
 32x32 blits (blits/sec): -1.16795e-22 -1.16795e-22 -4.41913e+176 -8.86953e-19
Any idea?

[chiark]

Using LibSDL-1.2.5-slzaurus20050410_arm.ipk from Cresho's SNES package as that seemed to be the latest stable one I could find...

For the SL-C1000

Code: [Select]

$ ./bench
Display size = 480x640
Mode = 320x240, software
QT_GetMachine: /proc/deviceinfo/product is 'SL-C1000
'
 detected machine is 'Sharp SL-C1000'
QT_GetRotation: Read spec from '/tmp/qtembedded-zaurus/QtEmbedded-0.spec'
 spec is 'Transformed:Rot270:Vga:0'
 Rot=3, Qvga=0
QT_SetVideoMode: SL-C700 Style is Input style
QT_SetVideoMode: argSize=480x640
QT_SetVideoMode: qteSize=640x480
QT_SetVideoMode: fbSize=480x640
QT_SetVideoMode: qteRotation=3
QT_SetVideoMode: userRotation=-1
QT_SetVideoMode: sdlRotation=0
QT_SetVideoMode: qteKeyRotation=3
QT_SetVideoMode: sdlKeyRotation=0
Pitch = 320
Hardware surfaces avail  = 0
Window manager avail     = 0
Blitter hardware         = 0
Colorkey blit hardware   = 0
Alpha blit hardware      = 0
Software->Hardware accel = 0
Video memory             = N/A

Slow points test
Fast points test
Rect fill test
32x32 Blitter test
Mode = 320x240, hardware
Mode = 640x480, software
QT_GetMachine: /proc/deviceinfo/product is 'SL-C1000
a@a@ t@0t@x t@ t@0t@@t@
                       1]@'
 detected machine is 'Sharp SL-C1000'
QT_GetRotation: Read spec from '/tmp/qtembedded-zaurus/QtEmbedded-0.spec'
 spec is 'Transformed:Rot270:Vga:0'
 Rot=3, Qvga=0
QT_SetVideoMode: SL-C700 Style is Input style
QT_SetVideoMode: argSize=640x480
QT_SetVideoMode: qteSize=640x480
QT_SetVideoMode: fbSize=480x640
QT_SetVideoMode: qteRotation=3
QT_SetVideoMode: userRotation=-1
QT_SetVideoMode: sdlRotation=3
QT_SetVideoMode: qteKeyRotation=3
QT_SetVideoMode: sdlKeyRotation=3
Slow points test
Fast points test
Rect fill test
32x32 Blitter test
Mode = 640x480, hardware
                          320x240  320x240  640x480  640x480
                          software hardware software hardware
Slow points (frames/sec): 0.417384    N/A   0.0326085    N/A
Fast points (frames/sec):  41.8917    N/A    6.96125    N/A
   Rect fill (rects/sec):  536.688    N/A    106.312    N/A
 32x32 blits (blits/sec):  698.618    N/A    637.113    N/A
$                                                                          
SL-C760 to follow.  I suspect that SDL is not optimised to the latest and greatest PXA-270 in that lib, so a new lib might well help.  I'll contact Anton about this, as he mentions it in the 1.23 beta readme.

[willgan]

this small little program might come useful...
i can use it to get the best CFLAGS setting when i compile apps that uses SDL ..

[BlackCardinal]

But with flags = -03 -mcpu=iwmmxt -mtune=iwmmxt -march=iwmmxt , i get..
...
Any idea?

I checked my code for the time calculations and there is a minor bug which might cause an overflow and hence a math error in some situations.  I used a signed integer to store an unsigned value.  Try changing the line:

time_t starttime;

to

Uint32 starttime;

I had to dig to find it, but time_t is a signed 32-bit integer, at least on my Z.  I had originally copied the time code from the SDL "plasma" demo but I later changed the calls to the Unix system call time() to SDL_GetTicks() to improve the resolution without verifying that the return types were the same.

Otherwise, I suppose it might be a bug in the compiler.  I seem to recall there used to a rule of thumb that -O2 was the highest level of optimization that was reliable with gcc.  I don't know if that is still true or not.  What does the screen do when you run that version?  Does it run faster or slower than the non-wmmx build?

Also, I should probably mention that all of the tests are run in 8-bit color modes.  Since the Z's native mode is actually 16-bit, it might be worthwhile to add tests for that mode.  I wouldn't be surprised if 16-bit color modes were faster due to the elimination of the palette lookup.

[lardman]

I'm not sure whether SDL is optimised to use the w100 on my machine so I was wondering if anyone has tried the mplayer benchmark thing.

Using the Star Wars clip in this thread would be worthwhile as it does need to drop some frames & is very good quality: https://www.oesf.org/forums/index.php?showtopic=15325&st=0

Direct link: https://www.oesf.org/forums/index.php?act=A...pe=post&id=1002


Si

[GadgetGuy]

Using LibSDL-1.2.5-slzaurus20050410_arm.ipk from Cresho's SNES package as that seemed to be the latest stable one I could find...

I have found libSDL_1.2.6cvs-1_arm.ipk. Is that maybe a better version?