Is Anything Using Both Prosesors Yet ?


P

p00pty

Guest
I have noticed that everyones been over clocking there gp2x's to get over 200mhz from a single cpu, But if the unit has 2 cpu's totaling 400mhz why are people bothing over clocking at the moment when the should already be 400mhz to play with.
 
p00pty posted on Dec 17 2005 at 02:20 PM said:
I have noticed that everyones been over clocking there gp2x's to get over 200mhz from a single cpu, But if the unit has 2 cpu's totaling 400mhz why are people bothing over clocking at the moment when the should already be 400mhz to play with.

Because you don't get to just add two cpus together. Code has to be written to take advantage of both processors, something that isn't being focused on yet since the basic emulators aren't really done (besides DrMD).

Also, the cpus aren't what you think. One of them is a 2d chip.
 
Last edited by a moderator:
stuff is beguinning to take advantage of the 2nd CPU. The PSX emulator had a beta version with some usage of the 2nd CPU but it didn't add to the performance so it's being tweaked.

Dual CPU programming is hard and takes a fair amount of thinking to implement in a way that boosts performance but we will see software taking advantage of it as time goes on
 
mysql101 posted on Dec 17 2005 at 02:26 PM said:
p00pty posted on Dec 17 2005 at 02:20 PM said:
I have noticed that everyones been over clocking there gp2x's to get over 200mhz from a single cpu, But if the unit has 2 cpu's totaling 400mhz why are people bothing over clocking at the moment when the should already be 400mhz to play with.

Because you don't get to just add two cpus together. Code has to be written to take advantage of both processors, something that isn't being focused on yet since the basic emulators aren't really done (besides DrMD).

Also, the cpus aren't what you think. One of them is a 2d chip.
No....
There are two processors and a 2d chip.
 
Last edited by a moderator:
There are two independent CPU's that share cache. As well as a co-processor which is 2d Accelerator. I think.
 
gnaa ... people are so misinformed...

there are 2 CPU-Cores. One is a 920T ond one is a 940T.

920T:
- 16/16 kb cache
- mmu
- "leading" core

940T:
- 4/4 kb cache
- no mmu only a pu
- only has a (limited) memory-window

The two processors share the RAM and can not access it the same time.
 
it's not really a video coprocessor, that's just because gph don't understand it :)

also, the 940 can access the same amount of memory as the 920, but due to linux, it's impractical for it to access the first 32mb.
 
Squidge posted on Dec 17 2005 at 11:54 AM said:
it's not really a video coprocessor, that's just because gph don't understand it :)

also, the 940 can access the same amount of memory as the 920, but due to linux, it's impractical for it to access the first 32mb.

I was under the impression that it wasn't Linux but GPH's Linux.
 
Last edited by a moderator:
DijiTao posted on Dec 17 2005 at 06:46 PM said:
Squidge posted on Dec 17 2005 at 11:54 AM said:
it's not really a video coprocessor, that's just because gph don't understand it :)

also, the 940 can access the same amount of memory as the 920, but due to linux, it's impractical for it to access the first 32mb.

I was under the impression that it wasn't Linux but GPH's Linux.

No, the second processor doesn't have an MMU which means it cannot know where the virtual pages of a linux application's memory are mapped to on the physical memory. It's easier to restrict the second to processor to the upper 32MB where it can have free reign.

HTH,
Andrew
 
Last edited by a moderator:
Well, you could always use /dev/kmem to overwrite the kernel's syscall table, and then replace a user-accessible routine with code to run a kernel-only routine like kmalloc, call that (as it'll be called in the kernel context rather than a user-context), and then replace the original code before anyone else calls it. The kernel memory allocation function allows you to specify a contiguous chunk of memory which you can translate to a physical memory pointer in the first 32mb which you could pass to the second processor (whereas the user-level malloc function returns only non-translatable virtual addresses which may be several physical chunks of memory glued together with clever use of the mmu), but it's a lot of work when it's easier to just keep the 940 in the upper 32mb.
 
Squidge posted on Dec 17 2005 at 08:49 PM said:
Well, you could always use /dev/kmem to overwrite the kernel's syscall table, and then replace a user-accessible routine with code to run a kernel-only routine like kmalloc, call that (as it'll be called in the kernel context rather than a user-context), and then replace the original code before anyone else calls it. The kernel memory allocation function allows you to specify a contiguous chunk of memory which you can translate to a physical memory pointer in the first 32mb which you could pass to the second processor (whereas the user-level malloc function returns only non-translatable virtual addresses which may be several physical chunks of memory glued together with clever use of the mmu), but it's a lot of work when it's easier to just keep the 940 in the upper 32mb.

Heh, well when I said 'cannot' I meant 'can't unless you do something crazy' :D
 
Last edited by a moderator:
Squidge posted on Dec 17 2005 at 08:49 PM said:
Well, you could always use /dev/kmem to overwrite the kernel's syscall table, and then replace a user-accessible routine with code to run a kernel-only routine like kmalloc, call that (as it'll be called in the kernel context rather than a user-context), and then replace the original code before anyone else calls it. The kernel memory allocation function allows you to specify a contiguous chunk of memory which you can translate to a physical memory pointer in the first 32mb which you could pass to the second processor (whereas the user-level malloc function returns only non-translatable virtual addresses which may be several physical chunks of memory glued together with clever use of the mmu), but it's a lot of work when it's easier to just keep the 940 in the upper 32mb.

Warning: incomprehensibility above. Rated T for techy.
 
Last edited by a moderator:
mysql101 posted on Dec 17 2005 at 07:26 AM said:
p00pty posted on Dec 17 2005 at 02:20 PM said:
I have noticed that everyones been over clocking there gp2x's to get over 200mhz from a single cpu, But if the unit has 2 cpu's totaling 400mhz why are people bothing over clocking at the moment when the should already be 400mhz to play with.

Because you don't get to just add two cpus together. Code has to be written to take advantage of both processors, something that isn't being focused on yet since the basic emulators aren't really done (besides DrMD).

Also, the cpus aren't what you think. One of them is a 2d chip.

I tried to clear this up with my 2 processor thread, but it didn't get stickied, it was a poll, maybe that is why, but I still got people clicking on the 2d accelerator option dammit.

2 Main Processors, a 2d core, a video core, a post processor core, a camera processing core.

The processors are both full processors,

and LIZARDKING, that is a typo, go to The MMSP2 vendor homepage to see the actual specs.
 
Last edited by a moderator:
Wish I understood this low-level programming more. But wouldn't be ace to have a programming framework which would balance the load between the 2 processors.
 
So to cut a long story short, Do we have a 400mhz handheld, or will it never work like that
 
We'll if you want your answer that simple:

it will never work like that.
 
Someone correct me if I'm wrong. But I think I read that ZodTTD has used both processors in his latest version of the PSX emu. But still has some way to go before its really using them like he wants it too.
 
Back
Top