69 replies to this topic

[icurafu]

If both CPUs can't be accessing memory at the same time and the second CPU is now doing something with the data set up by the first one in memory wouldn't the first have to wait until the second is done acessing before it could continue processing which means changing contents of memory?  If the first cpu could continue processing while the second is processing they would have to both be accessing memory at the same time and Squidge said that can't be done (not including the caches which can be used by their own cores, but they are small) .

And to the flamers, I am just trying to figure out how this works, relax.

Both CPU's cant be accessing the same memory, of course they can both access memory at the same time just not the same bit.

Actaully. From what I understand. And I think this issue needs clarification.... Each CPU is allocated 16MB of mem.

And the system gets 32MB.

So, each CPU will have exclusive access to their own 16MB... space that will not be slowed down with mutual exclusion statements or resource grabbing.

So if one CPU handles the rendering, then that CPU store all the textures and models in that space without any fear that the other CPU would start touching its stuff.

I'm not sure how the CPUs can use the system mem.

[DaveC]

If both CPUs can't be accessing memory at the same time and the second CPU is now doing something with the data set up by the first one in memory wouldn't the first have to wait until the second is done acessing before it could continue processing which means changing contents of memory?  If the first cpu could continue processing while the second is processing they would have to both be accessing memory at the same time and Squidge said that can't be done (not including the caches which can be used by their own cores, but they are small) .

And to the flamers, I am just trying to figure out how this works, relax.

Both CPU's cant be accessing the same memory, of course they can both access memory at the same time just not the same bit.

Actaully. From what I understand. And I think this issue needs clarification.... Each CPU is allocated 16MB of mem.

And the system gets 32MB.

So, each CPU will have exclusive access to their own 16MB... space that will not be slowed down with mutual exclusion statements or resource grabbing.

So if one CPU handles the rendering, then that CPU store all the textures and models in that space without any fear that the other CPU would start touching its stuff.

I'm not sure how the CPUs can use the system mem.

Isn't that 16 MB thing just for linux? Throw out linux and doesn't that restriction dissapear?

[Eolair]

If both CPUs can't be accessing memory at the same time and the second CPU is now doing something with the data set up by the first one in memory wouldn't the first have to wait until the second is done acessing before it could continue processing which means changing contents of memory?  If the first cpu could continue processing while the second is processing they would have to both be accessing memory at the same time and Squidge said that can't be done (not including the caches which can be used by their own cores, but they are small) .

And to the flamers, I am just trying to figure out how this works, relax.

Both CPU's cant be accessing the same memory, of course they can both access memory at the same time just not the same bit.

Actaully. From what I understand. And I think this issue needs clarification.... Each CPU is allocated 16MB of mem.

And the system gets 32MB.

So, each CPU will have exclusive access to their own 16MB... space that will not be slowed down with mutual exclusion statements or resource grabbing.

So if one CPU handles the rendering, then that CPU store all the textures and models in that space without any fear that the other CPU would start touching its stuff.

I'm not sure how the CPUs can use the system mem.

Isn't that 16 MB thing just for linux? Throw out linux and doesn't that restriction dissapear?

It's the limitation of the current GPH Linux kernel. The GPH Linux uses 32MB of RAM, leaving 16MB for the 940T and 16MB which is unused but can be accessed with some tweaking. You can change it by making a new kernel or circumventing Linux altogether. Neither is easy and have their own problems and needless to say both will take a lot of time and effort.

I think we need to seperate hardware limitations from software limitations. The limits Linux sets are obviously software limitations which can be altered. The hardware limitations however, like the fact that only one CPU can access the memory during the same clock cycle, are set in stone and cannot be changed. According to Woogal and theoddbot the memory access limitation isn't a serious problem though.

(Disclaimer: All of the above are just uneducated guesses/hearsay. My knowledge is very limited )

Edited by Eolair, 11 November 2005 - 12:47 AM.

[icurafu]

If both CPUs can't be accessing memory at the same time and the second CPU is now doing something with the data set up by the first one in memory wouldn't the first have to wait until the second is done acessing before it could continue processing which means changing contents of memory?  If the first cpu could continue processing while the second is processing they would have to both be accessing memory at the same time and Squidge said that can't be done (not including the caches which can be used by their own cores, but they are small) .

And to the flamers, I am just trying to figure out how this works, relax.

Both CPU's cant be accessing the same memory, of course they can both access memory at the same time just not the same bit.

Actaully. From what I understand. And I think this issue needs clarification.... Each CPU is allocated 16MB of mem.

And the system gets 32MB.

So, each CPU will have exclusive access to their own 16MB... space that will not be slowed down with mutual exclusion statements or resource grabbing.

So if one CPU handles the rendering, then that CPU store all the textures and models in that space without any fear that the other CPU would start touching its stuff.

I'm not sure how the CPUs can use the system mem.

Isn't that 16 MB thing just for linux? Throw out linux and doesn't that restriction dissapear?

I guess so, but I dont think it is a linux restriction. The 32mb allocated to system is a linux restriction.

[DaveC]

It's the limitations of the current GPH Linux kernel. The GPH Linux uses 32MB of RAM, leaving 16MB for the 940T and 16MB which is unused but can be accessed with some tweaking. You can change it by making a new kernel or circumventing Linux altogether. Neither is easy and has their own problems and needless to say both will take a lot of time and effort.

I think we need to seperate hardware limitations from software limitations. The limits Linux sets is obviously software limitations which can be altered. The hardware limitations however, like the fact that only one CPU can access the memory during the same clock cycle, is set in stone and cannot be changed. According to Woogal and theoddbot the memory access limitation isn't a serious problem though.

I think as the console matures we will wean ourselves more and more from linux. Linux is nice to have now because we get stuff working quickly which is good for a new system. It will be a springboard to something better. In the future as more and more cpu and memory hungry apps like emus for SNES or NeoGeo start to come about linux will have to go. NeoGeo has big ROMs and will need as much memory as possible. I would bet alot of HB firmwares will be made that are fast, use very little RAM and are very small.

Edited by DaveC, 11 November 2005 - 12:36 AM.

[Digitalrat]

Not everyone wants to run only emulators DaveC... I wouldn't have bought the GP2X if the only features for all times are emulators.

[Cyclops]

I think as the console matures we will wean ourselves more and more from linux.  Linux is nice to have now because we get stuff working quickly which is good for a new system. It will be a springboard to something better.  In the future as more and more cpu and memory hungry apps like emus for SNES or NeoGeo start to come about linux will have to go.  NeoGeo has big ROMs and will need as much memory as possible.  I would bet alot of HB firmwares will be made that are fast, use very little RAM and are very small.

Have you tried linux yet

I wonder how big those snes roms are hmmmmm.

[Draken]

I doubt he's talking about the size of snes roms, but more about complicated stuff to deal with when emulating snes, like transparanties.

You could always wonder how big those NeoGeo roms are though.

[Azure]

Anybody have a mirror of the video with sound?

[Cyclops]

I doubt he's talking about the size of snes roms, but more about complicated stuff to deal with when emulating snes, like transparanties.

You could always wonder how big those NeoGeo roms are though.

I see he should have included an and/or then at best.