Xenon Development Kits available.... NOW ( Alpha version )

...

NT kernel and and subsystems can be ported in about a week, testing them and writing drivers is another thing...
 
Re: ...

Deadmeat said:
NT kernel and and subsystems can be ported in about a week, testing them and writing drivers is another thing...

That is why the first news of Microsoft's Xbox division working with Dual G5 workstation is dated quite a bit back in time and the "Alpha" Xenon Development Kit is only coming out now.
 
a bit ot, but since someone already asked about the nt port being 32 or 64 bit: Does anyone see (an) advantage/s (besides marketing and/or planning ahead for xbox 3 etc..) offsetting the associated bandwidth and memory costs in going with 64-bit addressing for xbox2. Coming even close to 4GB system ram seems highly unlikely and 32 bits (36 bits ?) virtual address length still seems plenty for a game console (to me at least).
 
PiNkY said:
a bit ot, but since someone already asked about the nt port being 32 or 64 bit: Does anyone see (an) advantage/s (besides marketing and/or planning ahead for xbox 3 etc..) offsetting the associated bandwidth and memory costs in going with 64-bit addressing for xbox2. Coming even close to 4GB system ram seems highly unlikely and 32 bits (36 bits ?) virtual address length still seems plenty for a game console (to me at least).

I see no advantage, they should use 32 bits addressing: this way they waste more cache space and more bandwidth for addresses.

It is a good marketing tool.
 
Re: ...

Panajev2001a said:
...the first news of Microsoft's Xbox division working with Dual G5 workstation is dated quite a bit back in time and the "Alpha" Xenon Development Kit is only coming out now.
yup, .. I remember quite well the person who was fired because of posting pictures of Apple G5 computers at one of Microsoft 's offices..:

http://www.michaelhanscom.com/eclecticism/2003/10/even_microsoft_.html

http://www.aaxnet.com/editor/edit034.html

http://www.macnn.com/news/21786
 
Re: ...

Wunderchu said:
Panajev2001a said:
...the first news of Microsoft's Xbox division working with Dual G5 workstation is dated quite a bit back in time and the "Alpha" Xenon Development Kit is only coming out now.
yup, .. I remember quite well the person who was fired because of posting pictures of Apple G5 computers at one of Microsoft 's offices..:

http://www.michaelhanscom.com/eclecticism/2003/10/even_microsoft_.html

http://www.aaxnet.com/editor/edit034.html

http://www.macnn.com/news/21786

MS is the biggest 3rd party software publisher on the Mac. So all the Macs aren't surprising. :)
 
Panajev2001a said:
PiNkY said:
a bit ot, but since someone already asked about the nt port being 32 or 64 bit: Does anyone see (an) advantage/s (besides marketing and/or planning ahead for xbox 3 etc..) offsetting the associated bandwidth and memory costs in going with 64-bit addressing for xbox2. Coming even close to 4GB system ram seems highly unlikely and 32 bits (36 bits ?) virtual address length still seems plenty for a game console (to me at least).

I see no advantage, they should use 32 bits addressing: this way they waste more cache space and more bandwidth for addresses.

It is a good marketing tool.


Well, i though 64bit processors DO give a little more than the memory-size advantage, in terms of performance. If the only real advantage of 64bit processors really is the fact that they can address up to 8TB of Ram (not sure about the number, i just know it's huge), then what was the point of using 128bit-like and 64bit processors already in older consoles?
 
what was the point of using 128bit-like and 64bit processors already in older consoles?
Strictly speaking I don't consider them 64/128bits. No one ever came forward to set down guidelines what's the official way to count 'bitness', so marketing and PR got a bit of fun out of the whole issue.

There is an "unofficial" checklist to count bitness that is unofficially agreed upon by people in HPC. Taking 64bit for eg. the processor must:
1) support 64bit addressing
2) have 64bit registers
3) have integer and floating-point units that perform 64bit operations and have 64bit precision
4) have a stack width of 64bit

Covering the 4 points is good enough to guarantee 64 "bitness". Most of the 64/128/whatever bits consoles/whatever fail points (1), (3) and (4).

As for how using a 'true' 64bit processor in XBox2 benefits...(outside of marketing)

- Faster double-precision computations, which should be theoretically twice faster than a 32bit FPU/IU. My question is how much of a gain this brings, since XBox2 design is likely to be GPU-centric. If 70% of the work is done by the GPU, we only get 30% load on the CPU. Then we assume that only half of that involves 64bit floating-point/integer operations...

Perhaps a dev can enlighten us about how much 64bit operations get run on a CPU in a "GPU-centric" game?
 
passerby said:
Covering the 4 points is good enough to guarantee 64 "bitness". Most of the 64/128/whatever bits consoles/whatever fail points (1), (3) and (4).
They ALL fail point (1), and as Panajev noted, there's no good reason for them to pass it for foreseeable future.
I think 64bit FP part is a bit dubious though, because FPUs are still "coprocessors" by definition. It would seem mighty odd to have a fullblown 64bit CPU (on all points) and say it's not 64bit because it didn't include a FPU unit.
Not sure about the naming for 4. (my crappy english and all :|) , by stack width, do you mean data path width?

If 70% of the work is done by the GPU, we only get 30% load on the CPU.
Er, are you limiting this exclusively to graphic rendering? Because in a normal application as a whole, you usually try to make both CPU and GPU run 100% of the time (under max load), that's kinda the point of having multiple units after all :p

- Faster double-precision computations, which should be theoretically twice faster than a 32bit FPU/IU.
Er, IIRC x87 is native 80bit, and Gekko's FPU is native 64bit, so that's been around for a long time. And again, if you're limiting it to graphics, there just isn't any real need for it (kinda like addressing).

Perhaps a dev can enlighten us about how much 64bit operations get run on a CPU in a "GPU-centric" game?
Skip the last part and just say "game".
On consoles, I can safely say that outside PS2 games, the answer would
be "not at all". On PS2 I have no exact answer, it depends what compiler does really, but integer arithmetic is native 64bit, so there should be at least some. But that's non-FPU again, so...
 
Not sure about the naming for 4
I'm refering to the stack which we are introduced to in assembly programming. It's usually a consequence of (1), but not always. I recall some pple demoing a memory application(can't remember what it is) to my collegues that somehow manages to address more than 4GB memory on 32bit systems.

Because in a normal application as a whole, you usually try to make both CPU and GPU run 100% of the time (under max load), that's kinda the point of having multiple units after all
Good point. But I was confused about the talk about Unreal engine being CPU-dependent and other engines less so. What does that mean actually? Or maybe such situations do not apply to consoles, where devs try to balance and optimize.

IIRC x87 is native 80bit
Totally forgot about that. :oops: My mistake. You are correct that most FPUs today(and yesterday) pass this requirement.


So the summary of the discussion is that XB2 having a 64bit CPU doesn't appear to have too much advantage. :?

All right, we'll settle for the "energy consumption and heat" advantage over pentiums and athlons. :D
 
passerby said:
I'm refering to the stack which we are introduced to in assembly programming.
Ah ok. I was confused a bit because a lot of modern CPUs don't implement a stack as such. They leave that to software - typically compiler reserves a couple of GPRs for Stack Pointers etc.

Good point. But I was confused about the talk about Unreal engine being CPU-dependent and other engines less so. What does that mean actually? Or maybe such situations do not apply to consoles, where devs try to balance and optimize.
It still applies - idea of running all different units at 100% is the ideal(and not really very common) case. Usually you will end up with more load on one side or the other, and when running several units in paralel, the speed of the whole system is at best that of the slowest one (or less, when your application is not running the units 100% in paralel).

If that happens to be the CPU, you end up cpu bound. Unreal engine tends to dedicate more CPU processing towards various tasks, and thus your application is more likely to end cpu bound.

So the summary of the discussion is that XB2 having a 64bit CPU doesn't appear to have too much advantage.
Don't underestimate the fact that there is still a lot of integer code out there that does benefit from 64bit. R5900 in PS2 can perform quite well when it's not fighting the lack of L2 cache.
 
Another interesting point - I wasn't aware that type long(or long long depending on the OS) is so commonly used. What is it used for, world coordinates?
 
Back
Top