OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> Graphics Speed, How fast is the hardware?
BlackCardinal
post Oct 18 2005, 08:45 PM
Post #1





Group: Members
Posts: 70
Joined: 9-March 04
From: Albany, Oregon USA
Member No.: 2,232



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?
Go to the top of the page
 
+Quote Post
Cresho
post Oct 18 2005, 08:58 PM
Post #2





Group: Moderators
Posts: 1,619
Joined: 29-October 03
From: Los Angeles
Member No.: 809



look for my snes and nes emulator......also look for my video tutorial and packages.............100 percent full speed.
Go to the top of the page
 
+Quote Post
lardman
post Oct 19 2005, 12:35 AM
Post #3





Group: Members
Posts: 4,515
Joined: 25-October 03
From: Bath, UK
Member No.: 464



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
Go to the top of the page
 
+Quote Post
chiark
post Oct 19 2005, 01:05 AM
Post #4





Group: Members
Posts: 191
Joined: 28-August 05
From: Leeds, England
Member No.: 7,969



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.
Go to the top of the page
 
+Quote Post
BlackCardinal
post Oct 19 2005, 12:59 PM
Post #5





Group: Members
Posts: 70
Joined: 9-March 04
From: Albany, Oregon USA
Member No.: 2,232



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... unsure.gif

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.
Go to the top of the page
 
+Quote Post
BlackCardinal
post Oct 19 2005, 07:48 PM
Post #6





Group: Members
Posts: 70
Joined: 9-March 04
From: Albany, Oregon USA
Member No.: 2,232



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
$ mplayer -benchmark -framedrop -nosound some_short_video.mpg

If 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
$ vlc -v --noaudio some_short_video.mpg 2>test.txt
$ grep -c skipped test.txt

For 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! biggrin.gif

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.
Go to the top of the page
 
+Quote Post
BlackCardinal
post Oct 20 2005, 03:59 PM
Post #7





Group: Members
Posts: 70
Joined: 9-March 04
From: Albany, Oregon USA
Member No.: 2,232



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

Attached File(s)
Attached File  bench.arm4.bin.tar.gz ( 54.92K ) Number of downloads: 17
 
Go to the top of the page
 
+Quote Post
willgan
post Oct 20 2005, 10:03 PM
Post #8





Group: Members
Posts: 84
Joined: 9-December 04
From: KL, Malaysia
Member No.: 5,869



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
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
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?
Go to the top of the page
 
+Quote Post
chiark
post Oct 21 2005, 12:31 AM
Post #9





Group: Members
Posts: 191
Joined: 28-August 05
From: Leeds, England
Member No.: 7,969



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
$ ./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.
Go to the top of the page
 
+Quote Post
willgan
post Oct 21 2005, 02:15 AM
Post #10





Group: Members
Posts: 84
Joined: 9-December 04
From: KL, Malaysia
Member No.: 5,869



this small little program might come useful...
i can use it to get the best CFLAGS setting when i compile apps that uses SDL ..
Go to the top of the page
 
+Quote Post
BlackCardinal
post Oct 21 2005, 10:26 AM
Post #11





Group: Members
Posts: 70
Joined: 9-March 04
From: Albany, Oregon USA
Member No.: 2,232



QUOTE(willgan @ Oct 20 2005, 10:03 PM)
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.
Go to the top of the page
 
+Quote Post
lardman
post Oct 25 2005, 04:56 AM
Post #12





Group: Members
Posts: 4,515
Joined: 25-October 03
From: Bath, UK
Member No.: 464



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: http://www.oesf.org/forums/index.php?showtopic=15325&st=0

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


Si
Go to the top of the page
 
+Quote Post
GadgetGuy
post Oct 25 2005, 05:04 AM
Post #13





Group: Members
Posts: 321
Joined: 29-August 05
From: Ontario, Canada
Member No.: 7,977



QUOTE(chiark @ Oct 21 2005, 03:31 AM)
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?
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 22nd October 2014 - 01:43 PM