Actual Mhz And Overclocking?

[MilanC]

So you mean even a terminal-based "snake" game could push the processor to 900MHz

 

[CandidStan]

Wow, I seldom had such a clear answer. As with the GP2X, overclocking can reduce the life of the CPU. Is that the same with the Pandora?

Overclocking doesn't reduce the life of a CPU. Overvolting and overheating does. It can reduce the life of the processor, but even if it was 10 years instead of 25 years; do you really see yourself using a GP2X or Pandora (MK1) in 10 years?

Secondly, the maximum allowed software voltage for the OMAP is still within spec, so it shouldn't reduce it's life at all (unless of course you have a thing about playing the Pandora whilst inside large ovens, in which case, you'll probably cook before the Pandora dies )


The last thing I want is a Fan-dora

 

[Squidge]

I think someone misread my post...

 

[Pleng]

I am happy with that, I can't see playing at 900mhz for any length of time something that requires that much horsepower (if it needs to be clocked that high, chances are it needs even more and isn't really playable).

Excuse me? Are you're saying there's absolutely NO software that would struggle at 60Mhz but be playable at 900? If it needs more than 600, it will also require more than 900?

I'm pretty certain Zodds N64 emulator, for starters, would benefit significantly from an extra 50% cpu power.

 

[MilanC]

Well, loop 'til time to move to next block instead of rendering next frame.
Ok, it would take very, VERY bad code.

 

[canguy247]

44000hrs works out to 15 years @ 8hrs/day. I don't thinks the Pandoras will be used for much longer than that.

 

[AireTamStorm]

Optimally I see a daemon controlling clock, with maybe some extreme application talking to the daemon to kindly negotiate a temporary overclock. I've already decided I'd use such an approach should I ever have enough stuff on the screen to warrant it.

Anyone know how many cycles the OMAP takes to scale frequencies?

 

[A_SN]

Of course, people have to learn to free those cycles. If you sit there in a loop waiting for a fps timer to expire before drawing the next frame, it's going to run at full speed all the time and eat batteries. People need to learn that if they are not going to do anything useful with processor cycles, to return them to the OS.

Oh, and how would we do that properly?

 

[Tinnus]

There should be some kind of sleep function there

 

[Squidge]

Oh, and how would we do that properly?

Wait for an event rather than sitting in an infinite loop. Eg. wait for a certain time period to expire - you'll know how long it took to render the frame you just drawn, you'll know how long it needs to last, so you can wait before you need to draw the next frame.

 

[Dio]

Yeah. If you've got a hard timing event that the OS' scheduler understands you can wait on that and the scheduler will put your thread to sleep until that event hits.

If you don't have a hard event (e.g. you can't wait for vsync on Windows) you instead calculate how long you have to wait, and yield for some percentage of that time, then do a busy wait right up to the line. The closer you get to the line the more CPU idle you will get, but the greater the risk that some other thread sneaked in under you and grabbed a bit of time.

 

[MilanC]

QUOTE
Optimally I see a daemon controlling clock, with maybe some extreme application talking to the daemon to kindly negotiate a temporary overclock. I've already decided I'd use such an approach should I ever have enough stuff on the screen to warrant it.

You could use "userspace" + cpufreqd/powernowd.
I think "conservative" or "ondemand" cpufreq policy (-> everything controlled in-kernel) would be better, though - no need for the userspace app.
QUOTE
Anyone know how many cycles the OMAP takes to scale frequencies?

:unsure: I'd like to know that, too.