Pugger said:
They are fundamentally different but share some parts of their architecture. If even that.
So, 1 PE after-all or is this just for GDC 2005 ?
- Thread starter Panajev2001a
- Start date
They are fundamentally different but share some parts of their architecture. If even that.
Panajev2001a
Veteran
I think the Xenon's CPU cores are customized from the same core that produced the PU for CELL.
In a sense they are both using CELL
.
What are the customizations that made it into Xenon's CPU cores (that Microsoft had requested) ? What is the reference new core that gave birth to the PU and Xenon's CPU cores ?
1.) The first question is interesting (we heard that some of these customizations were done due to strong demand by Microsoft and they caused some trouble to IBM, that is they were not easy to make):
a.) One customization might be the way the L2 cache is shared (and updated) between the three multi-threaded cores and part of it can be locked and used to allow easy two way communication (nice buzz-word) between CPU and GPU. On CELL this might have not been needed as communication between CPU and GPU was choosen to be handled through DMA transfers maybe directly over the Redwood I/O link (DMA transfer from one of the APU's Local Storage to VRAM or vice-versa [it would be started by an APU or the PU, I do not know if DMA transfers will be exposed to the programmers on the GPU... they will be handled by the GPU itself and the programmer will be able to push data into/pull data out to/from the GPU working on the CPU side) or using main RAM as middle ground between CPU and GPU (both would be able to access main RAM then).
b.) Other ideas ?
2.) Is this the famous PowerPC 3xx series ?
In a sense they are both using CELL
.What are the customizations that made it into Xenon's CPU cores (that Microsoft had requested) ? What is the reference new core that gave birth to the PU and Xenon's CPU cores ?
1.) The first question is interesting (we heard that some of these customizations were done due to strong demand by Microsoft and they caused some trouble to IBM, that is they were not easy to make):
a.) One customization might be the way the L2 cache is shared (and updated) between the three multi-threaded cores and part of it can be locked and used to allow easy two way communication (nice buzz-word) between CPU and GPU. On CELL this might have not been needed as communication between CPU and GPU was choosen to be handled through DMA transfers maybe directly over the Redwood I/O link (DMA transfer from one of the APU's Local Storage to VRAM or vice-versa [it would be started by an APU or the PU, I do not know if DMA transfers will be exposed to the programmers on the GPU... they will be handled by the GPU itself and the programmer will be able to push data into/pull data out to/from the GPU working on the CPU side) or using main RAM as middle ground between CPU and GPU (both would be able to access main RAM then).
b.) Other ideas ?
2.) Is this the famous PowerPC 3xx series ?
Oh no! Vince will need to find a new crusade.Panajev2001a said:In a sense they are both using CELL
Seriously does IBM have more interest in one design winning (for their own use) over another? Specifically, since the IP involved with both designs are held by multiple parties does any agreement for cross licensing make one design a preferable foundation for IBM's own business outside of the console market?
That roadmap slide as of May 2004 shows 3 lines, and the 970 custom processor line in the middle is captioned as "Desktop/Game". So, if the PPC 300 65nm embedded core (I doubt its existence though) is a core for the Cell PU, it seems at least one of other consoles use other cores in the 970 line (in the same line there's 750cx for Gekko).AzBat said:
Oh, one more thing about Power. In the Cell Processor feature set disclosed in the first press release, it contains "Supports multiple operating systems". It means it has the hardware virtualization feature (Micro-Partitioning/IBM Virtualization Engine) which is currently only seen in IBM server line processors (POWER5). Consequently, if the Cell PU is something derived from PPC970 or PPC440, then it has to be heavily modified.
Microsoft surely doesn't want this feature in Xenon, for their OS is Windows anyway
Microsoft surely doesn't want this feature in Xenon, for their OS is Windows anyway
Panajev2001a
Veteran
I think that IBM might use CELL outside the gaming consoles a bit more... but then again... we will see.
The Xenon's CPU using this new core and this new VMX unit might find space in Apple's Notebooks... it is a different processor that innovates on the CPU core side, but pushes less forward IMHO on the Vector/Multi-media processing side to have a balance bent a little bit more toward General Purpose Processing. The super-VMX units are tied closer to the PU's and can benefit too from being so close and more limited in their independence from the PU'srogrammer's and compilers might fin a bit easier in some tasks to program for the VMX units than the SPU's/APU's even though the big problem of writing multi-threaded and SMP friendly code will overshadow that issue.
IBM might push both designs along with the base PU design... they do not see as a big problem having muliple lines, targeted to different or even similar markets, but using different architectures to power them.
The Xenon's CPU using this new core and this new VMX unit might find space in Apple's Notebooks... it is a different processor that innovates on the CPU core side, but pushes less forward IMHO on the Vector/Multi-media processing side to have a balance bent a little bit more toward General Purpose Processing. The super-VMX units are tied closer to the PU's and can benefit too from being so close and more limited in their independence from the PU's
rogrammer's and compilers might fin a bit easier in some tasks to program for the VMX units than the SPU's/APU's even though the big problem of writing multi-threaded and SMP friendly code will overshadow that issue.IBM might push both designs along with the base PU design... they do not see as a big problem having muliple lines, targeted to different or even similar markets, but using different architectures to power them.
Panajev2001a
Veteran
one said:Oh, one more thing about Power. In the Cell Processor feature set disclosed in the first press release, it contains "Supports multiple operating systems". It means it has the hardware virtualization feature (Micro-Partitioning/IBM Virtualization Engine) which is currently only seen in IBM server line processors (POWER5). Consequently, if the Cell PU is something derived from PPC970 or PPC440, then it has to be heavily modified.
Microsoft surely doesn't want this feature, for their OS is Windows anyway
Good post.
Panajev2001a
Veteran
one said:
Listening to what Deano had to say about the CPU cores in CELL and in Xenon's CPU (very similar requirements and likely optimizations, basically the same people working on both... this smells like similar end-results to me
) and thinking that nobody has yet talked much about the PowerPC CPU that will go into Revolution/NES5 I think that CELL and XCPU2 (the name I am going to use to describe Xenon's PowerPC based CPU) are architectures that use the supposed PowerPC 3xx derivate and build around it a new chip family while Revolution/NES5 uses a PowerPC 970 derivate (the core for "Gaming").What do you think ?
Panajev2001a said:Listening to what Deano had to say about the CPU cores in CELL and in Xenon's CPU (very similar requirements and likely optimizations, basically the same people working on both... this smells like similar end-results to me
What do you think ?
Well, I don't know the reason why Xenon is thought to use a PowerPC 3xx derivate if it's something developed after PPC 440. Can it be clocked at 3.5Ghz+? Also, scalability requirement for Xenon CPU looks like lower than Cell, so using a tiny core seems nothing more than the cost reason. Is the lowest power usage/heat really required for a console?
Btw, "basically the same people working on both"... I think you mean M. Gschwind on "Contributions to IBM's family of state-of-the-art processors", but who other do you mean?
Oh of course - the S|APUs are pretty certainly a completely new ISA - I wasn't implying paralels between whole architectures, or even less - programming models (which look to be very different at the moment), just the PPCs cores which both of them use.Mythos said:
And can it be clocked to 4Ghz+?one said:
Just because both Xenon cpu and Cell PUs could be derived from same core, it doesn't mean that core must be an existing PPC derivate, does it?
Clean sheet design and all?
With 3 PPC cores, those 'super' VMX units with two 128*128 register files each, 1MB of L2 cache, L1 caches, DMA controllers etc. you're not exactly talking about a small die you know.
And we don't know yet how 'tiny' the PPC core is or isn't
For those 'super' VMX units, they can go with the alternative implementation described in the recent patent - as at least one core is always a 'host' CPU core if they don't rely on threads too much, it can omit its VMX unit.Fafalada said:With 3 PPC cores, those 'super' VMX units with two 128*128 register files each, 1MB of L2 cache, L1 caches, DMA controllers etc. you're not exactly talking about a small die you know.
And we don't know yet how 'tiny' the PPC core is or isn't
Anyway, the 1st-gen Cell may have a different PU from that in the Broadband Engine or other variations of Cell, who knows
Excellent. What an interesting and informative thread 
It's really amazing how much more infomative a thread can be without certain people insulting everyone.
Bravo. So what do all of you think about porting between consoles. will the simularities (as small as they may be) assist in writting code game code that doesn't need to be rewritten each time? Or will it be basically about as challenging as it currently is.
It's really amazing how much more infomative a thread can be without certain people insulting everyone. Bravo.
So what do all of you think about porting between consoles. will the simularities (as small as they may be) assist in writting code game code that doesn't need to be rewritten each time? Or will it be basically about as challenging as it currently is.Sony PS3 = 1 PU
Sony Stereo = 1 PU
Sony Toaster = 1 PU
PS3 to optical cable (bi-directional) -< Stereo & toaster = 3 PU = CELL????????
These are things that go through peoples heads - speculation speculation speculation.
Sony needs to release more info, just like Team Ninja says.
Sony Stereo = 1 PU
Sony Toaster = 1 PU
PS3 to optical cable (bi-directional) -< Stereo & toaster = 3 PU = CELL????????
These are things that go through peoples heads - speculation speculation speculation.
Sony needs to release more info, just like Team Ninja says.
Qroach said:Excellent. What an interesting and informative thread
Bravo.
I think it's going to get MUCH harder. I think we will see more exclusives this next generations.
The mutliplatform games will look poor compared to first party games even more than they do now.
I think its true that game prices are going to go up.
I think we'll see less exclusives FWIW. But this has more to do with development cost than ease of porting.
Aguably something written to run efficiently on a Cell like architecture could probably be made to run efficiently on Xenon. Since you've commited to data locality and a host of other things that reduce the stress on the memory system. Of course that doesn't account for any performance delta between the two or running vertex shaderts in different places or what ever. It also potentially wouldn't be the most efficient way to do an operation on Xenon.
Flipping that agument, something written to run optimally on Xenon could potentially be a real bear to port to a Cell like architecture. If you assume a shared memory model, it's going to be potentially difficult to port to a segmented one. One example might be a game that relies heavilly on a scripting language and distribute the scripts across multiple processors on Xenon. It may not be possible to do that on a Cell like architecture, because the combination of the interpreter and the associated global structures would blow the limited APU/SPU code space.
Personally I think for the most part you'll see people use the parallelism for the easy stuff, better graphics for the most part, and physics when they have a 3rd party library that will deal with it for them. The majority of the game code will probably continue to be single threaded, but I could just be being jaded.
Aguably something written to run efficiently on a Cell like architecture could probably be made to run efficiently on Xenon. Since you've commited to data locality and a host of other things that reduce the stress on the memory system. Of course that doesn't account for any performance delta between the two or running vertex shaderts in different places or what ever. It also potentially wouldn't be the most efficient way to do an operation on Xenon.
Flipping that agument, something written to run optimally on Xenon could potentially be a real bear to port to a Cell like architecture. If you assume a shared memory model, it's going to be potentially difficult to port to a segmented one. One example might be a game that relies heavilly on a scripting language and distribute the scripts across multiple processors on Xenon. It may not be possible to do that on a Cell like architecture, because the combination of the interpreter and the associated global structures would blow the limited APU/SPU code space.
Personally I think for the most part you'll see people use the parallelism for the easy stuff, better graphics for the most part, and physics when they have a 3rd party library that will deal with it for them. The majority of the game code will probably continue to be single threaded, but I could just be being jaded.