Pandora outdated?

[ari64]

I've got a BeagleBoard-xM, and Ari also made a post about how he tried running N64 on the DM3730, didn't give a huge speedboost.


According to various posts I found on the internet, the DM3730 doesn't go higher than 1,2GHz when overclocking.


I'd love to do more tests on that myself, but that's what I found so far.


The BeagleBoard-xM doesn't feel faster for me than my Pandora does (running ArchLinux ARM on both as a test).

I assume it would be a bit better if the RAM clock was increased to 200MHz.  At 166Mhz (same as 3530) there wasn't much improvement.  I wasn't able to overclock much above 1.2GHz, but the failure mode was a bit unusual.  At 1.3 GHz, the core kept running but the I/O became unstable.  For example it would get random errors from the SD card.

NC10 is running the usual 1.6GHz Atom, are you sure you're running it only 1GHz? That netbook is single core too, although it has hyper threading so you do benefit from threading. That should be an even stronger case for what two real cores can do; you should compare with and without HT enabled if you can.

Atom N450 has a power management feature where it clocks down to 1.0GHz.  You can alter this behavior with the cpufreq utils under Linux.

 

[DaMummy]

heres a dumb idea that the slashgear and engadget will eat up....ship pandoras with default overclock to 1ghz. so instead of an OS crash booting back into 500mhz, just let it boot into 1ghz by default

 

[WizardStan]

heres a dumb idea that the slashgear and engadget will eat up....ship pandoras with default overclock to 1ghz. so instead of an OS crash booting back into 500mhz, just let it boot into 1ghz by default

A sufficiently large percentage can't clock that high. Those that can still wouldn't be stable under all conditions, one crash and it would be returned as faulty. And it would make a noticeable dent in the battery by having to increase the OPP to max.

 

[elwing]

However, I'd need to find 2000 customers who would want to pay about 24 EUR more right away, which would probably take another month.


So it would delay everything another 4 months from now on...


I doubt that's a good thing

on the contrary, an excuse for delay is always welcome...

 

[ImmaculateChimp]

14) If you're telling me to run my Pandora at 800MHz that means I can change the voltage without voiding my warranty, right? Because at OPP3 my Pandora doesn't survive NEON code at 800MHz w/o freezing.

Sure, whatever the OS allows is within warranty.


OPP5 is within TIs specs, and that's the maximum the stock OS allows.


notaz is currently working on Kernel 3.2, which adds some OMAP stuff following TI's specifications.


The kernel forces OPP4 on >=550MHz, OPP5 on 600MHz.

Is that something the kernel will do or is doing? Also, I'm sure I must not be understanding something, is he basically saying that kernel 3.2 will effectively eliminate OPP3 and OPP4, assuming you aren't going to underclock the Pandora? :huh: :unsure: (so, if you run PCSX ReARMed at standard clock speed you'll actually be over-volting the Pandora? )

 

[EvilDragon]

the mainstream kernel IS doing this.


this is where we have to do our custom kernel, since we don't want it like that.

 

[Thorium]

I think for desktop use the current CPU is ok. For gaming its never good enough. The most important games of the Pandora are emulated. A dual core would make a huge impact on Saturn emulation, making it playable.


And lets talk about x86 emulation. There is no CPU good enough for x86 emulation. Higher CPU clocks instantly enable more x86 games to run. And there is no end to x86 emulation, it will never be good enough because there are allways newer games that will not run or to slow.


I still dont have my Pandora and i still want it. But there is a need for a faster CPU, there allways is.

 

[notaz]

A dual core would make a huge impact on Saturn emulation, making it playable.

That's not necessary true, emulators are hard to parallelize.

 

[sukhi2011]

There is no use cortex A9 if it will run same emulators and they will be no use p2 at all.


As you say ed about cortex A15 if that push boundaries making new emulators that will be much better,to be honest we need go beyond n64 emulation.


We don't need new hardware playing same emulation that will be awful,we need to get the new p2 have better hardware and cpu inside the system.


P1 is best system to have like mini pc in your hand, nothing can beat that and all usb connectivity plus all programs it used are marvellous at the end of the day this is not normal games system or smart phone it's 2 world's in one gaming console/mini pc.

 

[fusion_power]

I think for desktop use the current CPU is ok. For gaming its never good enough. The most important games of the Pandora are emulated. A dual core would make a huge impact on Saturn emulation, making it playable.

But the Pandora is stil la MOBILE Device, and there it all depends on battery life. Nobody wants a mobile dual or quadcore CPU that may be fast but only results in 2h battery life or even less.

 

[Grench]

I'm probably simplifying it too much though. I'm sure there is more to it than that. The initial DM3730 purchase cost would be more capital outlay - and there are politics and sentiment to account for. Still, the chance to have existing customers have something to make them repeat customers is, in my humble opinion, a pretty big deal.

Yep, sadly, it's not that simple.


First off, nobody will buy the old OMAPs. They've been lying around for about a year now, and although they're good, nobody will take the risk (unless you sell them for a way too low price).


Next, the DM3730 has a leadtime of about 6 weeks.


Meaning: If I order and pay it now, I won't see it before 6 weeks.


However, I'd need to find 2000 customers who would want to pay about 24 EUR more right away, which would probably take another month.


So it would delay everything another 4 months from now on...


I doubt that's a good thing

Alright - then lets get those 512MB "Old OMAPs" loaded onto boards and sold...


Have you thought through the ideas of a board replacement upgrade program?


You could :


Charge me (and those like me) for the board plus a core charge (value of my old board).


Then send me a new 512MB board.


I swap them out and send you back my old board.


You inspect/test my old board - if it passes, you refund me the core charge.


That is how rebuilt auto parts are sold in the US.

 

[Exophase]

But the Pandora is stil la MOBILE Device, and there it all depends on battery life. Nobody wants a mobile dual or quadcore CPU that may be fast but only results in 2h battery life or even less.

In newer SoC perf/W goes up in general, idle power consumption goes down, and more power saving features are added. Faster processors are better for battery life. Having more cores and higher clock frequencies available doesn't mean you have to always exercise them.

 

[CAZMIESTER]

But the Pandora is stil la MOBILE Device, and there it all depends on battery life. Nobody wants a mobile dual or quadcore CPU that may be fast but only results in 2h battery life or even less.

In newer SoC perf/W goes up in general, idle power consumption goes down, and more power saving features are added. Faster processors are better for battery life. Having more cores and higher clock frequencies available doesn't mean you have to always exercise them.

Is it not fact that newer socs have a sub cpu running at a lower clock rate for apps that req less omph. like the new tegra.

 

[Thorium]

A dual core would make a huge impact on Saturn emulation, making it playable.

That's not necessary true, emulators are hard to parallelize.

It should be very doable on the Saturn emulator as the Saturn is a multi CPU system.

 

[notaz]

A dual core would make a huge impact on Saturn emulation, making it playable.

That's not necessary true, emulators are hard to parallelize.

It should be very doable on the Saturn emulator as the Saturn is a multi CPU system.

It doesn't work like that, usually it's not possible to efficiently emulate multi CPU system in threaded way because those emulated CPUs are interacting far too often. For example, IIRC, Ari64 mentioned SH2s on Saturn need to be synchronized ~10 times per scanline for reasonable compatibility, that's at least ~157200 times per second. You'd have to use use expensive thread synchronization primitives that many times, so this would only make things crawl, not speed up. Perhaps it would be possible to do rendering on separate thread, but that's still problematic in practice.

 

[Bosbeetle]

I never cared for being up-to-date, we had a msx until way into the 90s. (I think we got rid of it around 94, sadly ;()

 

[ZXDunny]

A dual core would make a huge impact on Saturn emulation, making it playable.

That's not necessary true, emulators are hard to parallelize.

It should be very doable on the Saturn emulator as the Saturn is a multi CPU system.

It doesn't work like that, usually it's not possible to efficiently emulate multi CPU system in threaded way because those emulated CPUs are interacting far too often. For example, IIRC, Ari64 mentioned SH2s on Saturn need to be synchronized ~10 times per scanline for reasonable compatibility, that's at least ~157200 times per second. You'd have to use use expensive thread synchronization primitives that many times, so this would only make things crawl, not speed up. Perhaps it would be possible to do rendering on separate thread, but that's still problematic in practice.

Ironically enough, emulating single-CPU systems lends itself well to multi-threading - when the main CPU emulation has done enough work for a frame, you can send the emulated video RAM off to a separate thread for rendering and get on with the next frame in the parent thread. Doesn't work very well for sound, but definitely more than one core can be a real bonus for video rendering, especially if you're using custom scaling algorithms and overlays.


D.

 

[Exophase]

Ironically enough, emulating single-CPU systems lends itself well to multi-threading - when the main CPU emulation has done enough work for a frame, you can send the emulated video RAM off to a separate thread for rendering and get on with the next frame in the parent thread. Doesn't work very well for sound, but definitely more than one core can be a real bonus for video rendering, especially if you're using custom scaling algorithms and overlays.

D.

Most 2D game consoles allow effects mid-frame (scanline by scanline, or even mid-scanline) thus also requiring a lot of synchronization or event queuing if you want to do it in another thread. Latter can be more expensive than it's worth, depending on what the game is doing. Also what does the type of video have to do with whether the system has one or more CPUs?

 

[pmprog]

Most 2D game consoles allow effects mid-frame (scanline by scanline, or even mid-scanline) thus also requiring a lot of synchronization or event queuing if you want to do it in another thread. Latter can be more expensive than it's worth, depending on what the game is doing. Also what does the type of video have to do with whether the system has one or more CPUs?

From my understanding of the C64. Effectively, the VIC2 will produce a continuous TV stream line by line, whilst it's contents were updated by the main CPU. This allowed for multiplexing sprites by after the scanline had finished on the last line of the sprite, changing the position to further down the screen, changing gfx etc.


So you could use one core to read the emulated video buffer and output the "TV" scanline stream, and leave the other core to emulate the CPU, that would allow you to do raster effects like sprite multiplexing quite easily I think

 

[ZXDunny]

Ironically enough, emulating single-CPU systems lends itself well to multi-threading - when the main CPU emulation has done enough work for a frame, you can send the emulated video RAM off to a separate thread for rendering and get on with the next frame in the parent thread. Doesn't work very well for sound, but definitely more than one core can be a real bonus for video rendering, especially if you're using custom scaling algorithms and overlays.

D.

Most 2D game consoles allow effects mid-frame (scanline by scanline, or even mid-scanline) thus also requiring a lot of synchronization or event queuing if you want to do it in another thread. Latter can be more expensive than it's worth, depending on what the game is doing. Also what does the type of video have to do with whether the system has one or more CPUs?

Yes, the last round of emulators I worked on produced mid-scanline colour changes and such. We found, while developing, that it was much easier to just store such changes in a temporary buffer, which was much quicker than decoding screen RAM every TState - and a separate thread to do the decoding at the end of each frame. Because the video decoding was done in a separate thread, it could run at low priority and not get in the way of the main thread when it needed CPU time - produced an instant auto-frameskip because the it only ran when the main CPU thread was idling waiting for sound synchronisation.


As to your second question, having more than one CPU meant that the video thread could run on a separate CPU core which led on slower systems to a much better video update. When the video decoding was added to custom scaling (using overlays, scalines, CRT simulation and scalers such as HQ4x) the system really came into its own on slower systems - no audio skipping, with frameskipping where it was needed and a much smoother experience, as we seem to be more tolerant of a dropped video frame rather than a stutter in sound.


Granted, we were targetting as low a CPU as we possibly could (one of the emulators is quite happy running on a 486 DX-2 50MHz, but in general we aimed for about 333MHz), but that was a bonus as there was no deleterious effect on more powerful systems. It worked very well where single-threaded emulators would struggle. Of course, you do need to be emulating a system that you can use this approach with, and more than one emulated CPU very often needs synchronisation between them and in that case multi-threading would be no advantage at all.


I use two threads in PandaBAS - the main input loop and display update are in one thread, and the interpreter runs in another higher priority thread. On multicore systems it's very fast, but on the Pandora it's not particularly quick, so might well benefit from a better approach. But then, I wrote it for x86 systems before I decided it might be fun to try on a Panda.


D.