Pandora Sgx Driver Benchmarks

[juniorm33]

All powernow, speedstep, gpu's, arm's built in power management do is lower the speed from the default to save power, not go above it.
So it still runs at the publicised/true speed when required.
Most processors will do this now.
As Mali said it's sometimes better to disable it though.

 

[craigix]

Those stats don't really impress me ,i hope the driver gets the full treatment
as i am currently playing quake 3 on the psp at 22/28fps - drops to 12fps when
all hell breaks loose.And well we already know quake 1 runs at a constant 60fps
on the psp and quake 2 runs at 30-40 fps.

I dont like to put against the psp but it's all i could think of at the time
but in light of those stats ,craig's vid looks minted and i would think
it was running at around 50-60fps and thats at a standard 500mhz so wow!

Paddy

The Pandora is running it at over THREE TIMES THE PSP RESOLUTION.

No actually it is exactly 2.9411764705882352941176470588235 times the resolution. Not over 3 times. Not trying to be a smart ass but your comment could have been worded better. You try to make the Pandora sound like the holy grail of gaming handhelds which right now the PSP has it beat totally cause I can go buy a PSP right this second but I can't get a Pandora and probably won't be able to for months. Granted I agree that the Quakes will be much more playable on the Pandora...when it becomes available.

Just for you I'll run it to overscan the LCD.

 

[kingoddball]

Someone seems grumpy.

 

[Kramy]

SpeedStep is irrelevant, the sleep states are much more important. I get the most battery life with disabled SpeedStep running at the highest clock all the time. Race to idle. When SpeedStep is enabled, the OS switches too late to the next higher clock, thus processes take longer and need more power.

HDDs guzzle power longer, too.

But if you have an SSD, that'd be less of an issue.

The thing about power management, is it's stupid in every single OS. No component takes other components into account. I don't care if the LCD dims while a page loads, if it brightens back up when it finishes, but you'll never see anything like that happening.

 

[Exophase]

Just for you I'll run it to overscan the LCD.

That comment made no sense ;p

 

[darkblu]

Just for you I'll run it to overscan the LCD.

That comment made no sense ;p

well, he could always make it render at some ridiculous resolution in a secondary render target and then downsample for the framebuffer ; ) as the psp cannot handle textures bigger than 512^2, pandora can easily beat that 3x ; )

 

[lulzfish]

Just for you I'll run it to overscan the LCD.

That comment made no sense ;p

well, he could always make it render at some ridiculous resolution in a secondary render target and then downsample for the framebuffer ; ) as the psp cannot handle textures bigger than 512^2, pandora can easily beat that 3x ; )

OMGZ HD QUEKE

 

[fraseyboy]

Those stats don't really impress me ,i hope the driver gets the full treatment
as i am currently playing quake 3 on the psp at 22/28fps - drops to 12fps when
all hell breaks loose.And well we already know quake 1 runs at a constant 60fps
on the psp and quake 2 runs at 30-40 fps.
Paddy

I can run Quake 3 at around 25fps on my phone but it doesn't mean it's more powerful than the Pandora.

 

[skeezix]

Ideally you would want to run a shell script upon execution of each program which configures all the clocks to their optimal speeds for each emulator.

Like if SNES emulation can run fine at 300mhz OPP2 or something like that with the SGX clocked at 55mhz, you'd save a good amount of battery life, then upon closing the emulator, trigger the usual speeds needed for basic desktop/browsing type use. Likely you could keep the SGX at 55mhz and only ramp it up for things that even need 3D.

There are so much possibilities to further extend battery life beyond the 10 hours, it sounds like much more will be possible after software gets optimized.

That is in fact what happens more or less .. if a pnd-file requests 200mhz (say), and that is allowed by the user, then the system downclocks, runs the pnd, and restores clock on exit. Sort of goofy if you're running 5 apps at once, but the user knows the risk of doing that (ie: slowing down other apps, and the whole risk of running 5 apps at once, etc.) Anyway, yeah, we do that

When the LCD is closed, we turn off the screen (but leave clock alone in case you're burnjing thrugh mp3s, say.) But if your mp3 player mneeds only 100mhz, set up a pnd for it that requests that, and bam, every time you run your mp3 player, you're running at 100mhz; close the lid, and you're talking pretty low consumption

Theres lots of options..

jeff

 

[Exophase]

well, he could always make it render at some ridiculous resolution in a secondary render target and then downsample for the framebuffer ; ) as the psp cannot handle textures bigger than 512^2, pandora can easily beat that 3x ; )

The funny thing is that Nintendo DS actually supports textures up to 1024x1024 in size, even though it only has room for one at 4bpp.

 

[marshal]

That is in fact what happens more or less .. if a pnd-file requests 200mhz (say), and that is allowed by the user, then the system downclocks, runs the pnd, and restores clock on exit. Sort of goofy if you're running 5 apps at once, but the user knows the risk of doing that (ie: slowing down other apps, and the whole risk of running 5 apps at once, etc.) Anyway, yeah, we do that

When the LCD is closed, we turn off the screen (but leave clock alone in case you're burnjing thrugh mp3s, say.) But if your mp3 player mneeds only 100mhz, set up a pnd for it that requests that, and bam, every time you run your mp3 player, you're running at 100mhz; close the lid, and you're talking pretty low consumption

Theres lots of options..

jeff

I am not a specialist but I don't understand the point of "per application" underclocking on a ARM chip.

First this seem quite complicated because people will run more than one application at a time.
Furthermore I don't really understand why this would be a good way to do power management. I always thought than those ARM devices could handle power management "by themselve" (I am sure there is a software side to it but not "per application"). The idea would be to run the current operation as quickly as possible and then go to sleep. From what I understood you would be better off finishing your task as fast at possible (or should I say in the most effecient performance/power usage mode).

Also are there a lot of ARM device out there that use "per application" downclocking. I don't belive android does this.
To take my nokia n800 as an exemple there is no setting to change the clock speed and I don't believe I head of people even wanting to do this. The n800 can last a long time (a few days) on standby if the wifi is off. Even with wifi on it does perform really well.
I believe the OMAP2 and power management in the nokia n800 "simply" put the CPU in an idle mode when it doesn't need to perform operation. And it works very well without application needing to define a clock speed to run at.

I would imagine the Pandora doesn't have such great power management for now. And I can fully understand this is not perfect for now. It is probabally quite complicated to put into place and well beyond my understand. What I am really critical of is the use of "per application" downclocking. I believe the focus should be on overall proper power management.
Maybe the "per application" downclocking is some sort of "emercency method" because power management is not yet very good on the Pandora. Personnaly I believe the "per application" way of doing it will do more arm than good in the long run.

This is only my opinion of course. Maybe I am missing some important point.

On the other side, I can understand the PND requesting to run the processor at a higher clock speed than 600mhz. This could be a acceptable user case because people may not want to run the processor overclocked at all time. So it would only be overclocked when you are running a high demanding game or application.

 

[juniorm33]

Marshal a simple example is, if you was running an mp3 player and it only needed to run at 100Mhz, or an emu that needed to run at 600Mhz (or automatically overclock).
This way you don't need to adjust the speed yourself, just start it up and it will automatically set to the correct speed.
So yea, ARM will use less power if all you was doing was playing an mp3 anyway even at 500Mhz, but not as little as if it was set to a lower frequency.
It's not about an emergency method.
I guess a good example is if you watch ED's vid you can see that the time left on the battery was changing dependent on what he was doing, this had nothing to do with the autospeed adjustment (as far as I know anyway)

If you don't want to take advantage of this, going by the way PND's have been designed you'll probably be able to override/switched off if you want. :lol:

Edit:
And just to point out, a lot of people like to underclock just as much as people like to overclock, so it's basically the same use case.

 

[MDave]

What happens if you open an emulator that wants to run at 500MHz, minimise it then you open up the mp3 player that wants to run at 100MHz, then resume the emulator? You'll be playing the emulator while the system is clocked at 100MHz?

 

[juniorm33]

Hence why (hopefully) it can be switched off, and it definitely can be overridden.
If your using one of the simple launchers you'd probably only be doing one thing at the time most of the time.

As said, it's convenient, don't have to use it.
Let me see (what happens without using this setting), you set it to run at 100Mhz when your playing your mp3, but then you decide to play an emu. Oh wait your going to have to change the speed to 600Mhz, otherwise it's running at 100Mhz.

I really can't see this difference apart from the times when it will be useful, otherwise you have to do the same thing anyway?
Again, this doesn't seem to be taking anything away from people who don't want to use it.

 

[WizardStan]

I always thought than those ARM devices could handle power management "by themselve" (I am sure there is a software side to it but not "per application").

The CPU doesn't do it automatically, the idle process needs to tell the CPU that it is running idle and that's what causes it to slow down. So it needs a significant amount of idle time. If the CPU doesn't receive these "you are idle, slow down" signals often enough, it ramps back up. I'm not entirely certain what the threshold is, but imagine it's 25%: if the CPU is used less than 25% average (idle more than 75%) then it starts slowing down. If it climbs above 50% usage at the current clock speed, it starts speeding it back up again. So obviously a lot of applications will easily fall within that threshold: an MP3 player that would only need 100Mhz to run effectively sits at 25% while it's clocked at 400Mhz using 4 times as much power (more or less). And then there are some applications that will happily suck down as much CPU as they can get when they don't actually need it. Slow these puppies down.
Further, the way it's designed, it's not just useful for underclocking, but also overclocking. If you download N64 emulator and it needs to overclock to 800 to run effectively, it says that in the PND file. You run it, it clocks up your CPU (voiding your warranty in the process, but it's N64 DUDE!) and away you go to portable Ocarinas!

 

[Kangal]

That is in fact what happens more or less .. if a pnd-file requests 200mhz (say), and that is allowed by the user, then the system downclocks, runs the pnd, and restores clock on exit. Sort of goofy if you're running 5 apps at once, but the user knows the risk of doing that (ie: slowing down other apps, and the whole risk of running 5 apps at once, etc.) Anyway, yeah, we do that

When the LCD is closed, we turn off the screen (but leave clock alone in case you're burnjing thrugh mp3s, say.) But if your mp3 player mneeds only 100mhz, set up a pnd for it that requests that, and bam, every time you run your mp3 player, you're running at 100mhz; close the lid, and you're talking pretty low consumption

Theres lots of options..

jeff

I am not a specialist but I don't understand the point of "per application" underclocking on a ARM chip.

First this seem quite complicated because people will run more than one application at a time.
Furthermore I don't really understand why this would be a good way to do power management. I always thought than those ARM devices could handle power management "by themselve" (I am sure there is a software side to it but not "per application").

The idea would be to run the current operation as quickly as possible and then go to sleep. From what I understood you would be better off finishing your task as fast at possible (or should I say in the most effecient performance/power usage mode).

@marshal

I agree with your thoughts.
Its better to use your device in the most effecient performance/power usage mode.
But that hardly means making your device run faster (causing system to use more battery power) to get the job done quicker, in fact more often the opposite.
I tried this on my old laptop (Turion X2) high performance vs power saver for converting video format (40min prison break episode divided into 2parts).
I used battery bar to track usage, and ofcourse high performance finished first but in the end i had 68% left (32% used).
I quickly switched to power saver and converted the other 20min part, when it finished i had 43% (25% used).
Yes I know thats shockingly bad figures, but I used that little exercise to determine how I should use my laptop to have more playtime on the move.
And yes what happened on x86 Vista can only partially imply the system for ARM, and in no way represent it.

I also agree:
And if you have an app that clocked your system to 600MHz (for instance) then opened another which downclocked to 300MHz, this would create an anamoly.
Cause if the first app was playing/unpaused it may start to freeze. And when you switched back to that app, it would be very slow then freeze the whole system.
Even if it didnt freeze the system, your Pandora would be running so slow which would take all the fun out of it.

@skeezix
But it is an interesting concept.
I was pondering about this the other day and trying to figure out a way to bypass the problem.
What can be done is that all apps can be coded (by author/tester) to run change the clock frequency to what is needed (rounded up), as you said.
But make the system sophisticated enough, that if the first app (over/down)clocks then another app is opened which wants to downclock further; the system chooses the higher clock frequency to prevent stopping and slowing of either apps.
This would mean switching between the two (multitasking) is much smoother and probability of crashes is lower.
And if the first app (600MHz) is closed but the second (300MHz) is still running, the system downclocks automatically to 300MHz.
The OS may be also loaded with a set of higher-order settings which prevent down/overclocking the system to certain limits (eg min250, max650).
And if an app tries <249MHz it auto sets to 250MHz instead, or if it tries +651MHz it auto sets to 600MHz.
Thus, OS developers can create a method where hardware damage is minimized.
But also have an option where the user overrides the system and manually changes the clock speed (within the 250-650 limit).
This way if the app dev stuffed up and coded the app to clock the system at 500MHz and the app is actually more demanding and causing the system to slow down (tortoise multitasking):
There is a way to fix it. The user can either close other apps OR overclock the system (eg to 600 or 650MHz) OR both.
And after the user has done with the app and closes it, the user can go back to settings and change the dynamic-clocking from manual (user) to auto (app coded).

I like to think this way you get to have your cake and eat it!
Because it means your device automatically gives you the best power effeciency without exploiting your experience (ie less crashes and smoother, refined multitasking).
It also means you have freedom with your device.
But the freedom is dumb-proof, preventing you from frying your device
All the figures (ie 250-650MHz) are hypothetical, just used to illustrate my point.


Would this be too difficult to implicate?
What are the disdvantages to such a system?
Is something like this already implimented (on Pandora or another system)?

PS I begin to see why iOSX doesn't have true multitasking.
Device was made dumb-proof so user experience is always smooth since hardware wasn't 100% upto scratch when iPhone was first released.

 

[kuru]

tl,dr; If you have different apps requesting different clock speeds, would there be anything preventing the system from either telling which app is in the foreground/active and using it's demanded clockspeed, or just taking the highest request and sticking to that (in case it's something that has to run full-speed in the background)?

You could also have a (configurable) popup that asks you about your speed preference.

 

[Exophase]

Clock speed can be adjusted based on total CPU load, rather than per application. Failing that, it is possible to task switch clock speed, depending on how quickly the transitions take place.

Running at full speed for 50% of the time then sleeping for 50% of the time must still be using substantially more power than running at 50% speed 100% of the time or CPUs wouldn't support frequency scaling. Even when sleeping you still need to have enough clocks running to be able to resume based on internal events like timer interrupts.

The scaling does come with pitfalls. I feel like I'm constantly fighting it on Linux, it's just too slow to realize my app needs full CPU, and it's especially bad when it keeps rescheduling it between cores.

 

[conso]

Could that be handled by an optimzed kernel-sheduler?

 

[Exophase]

Unless the scheduler is an oracle (can perfectly accurately predict the future) it's not possible to avoid problems entirely.