J Allard talks more on Xbox 2 hardware (still vauge)
- Thread starter Megadrive1988
- Start date
Megadrive1988
Veteran
unless Xbox 2 has hundreds of CPUs in it, which of course it won't, only 1 die, with 3 or more cores, I would be severely disappointed if Microsoft dropped the audio/communications processor. part of the reason for having the MCPX in Xbox is to free up the CPUs. that was a good thing.
(if only they could've made the memory segmented).... My feeling on seperate audio chip won't change with Xbox 2. just because it'll have more than 1 CPU core doesnt mean they should be burdened with audio processing. well okay, I suppose it won't really matter since audio processing is nowhere near as intensive as graphics processing.
as for Xbox 2 custom silicon, I very much hope Microsoft's graphics IP / resources / acquisitions are being put to use this time. they'll need every bit of inovation and hardwired features to overcome the near-certain processing performance gap between Xbox 2 and PS3.
okay, I better not say too much more on things I really have little undestanding of
(if only they could've made the memory segmented).... My feeling on seperate audio chip won't change with Xbox 2. just because it'll have more than 1 CPU core doesnt mean they should be burdened with audio processing. well okay, I suppose it won't really matter since audio processing is nowhere near as intensive as graphics processing.
as for Xbox 2 custom silicon, I very much hope Microsoft's graphics IP / resources / acquisitions are being put to use this time. they'll need every bit of inovation and hardwired features to overcome the near-certain processing performance gap between Xbox 2 and PS3.
okay, I better not say too much more on things I really have little undestanding of
maybe I'm sidetracked and missed the point in the article, but I thought the whole point of XNA was basically that the devs wouldn't be coding on the processors directly, but entirely on the middleware. That would mean that all processors would vanish as a piece of hardware, as XNA would take care of all that. I still expect that there is dedicated hardware, just that devs won't actually "see" it.
No amount of middleware will hide the hardware that well in a console (at least until were working on virtualised machines). Making things run well on multi-processor (with some asymmetries like a graphics or sound processor) transparently is just about impossible (at least while we are programming in C).
Of course their is some dedicated hardware just not a lot...
Of course their is some dedicated hardware just not a lot...
wco81 said:
Hey!!! farflung?!?!
bleon said:
It's really hard to produce procedurally generated content that looks good enough and can hide it's mathematical origins. Simple fractal noise textures repeat far too much, you have to layer and layer and layer them, which results in horribly complex shaders.
Pixar went very procedural on the enviroment in Bug's life, and while it looked good, it had some 2MBs of shader code IIRC. There's no way even a next-gen console could handle such complexity... And I think even Pixar has abandoned this approach as well, or at least started to mix in manually built content. They also have a very stylized look in their movies, which helps them somewhat.
Phil said:
To be honest, nobody outside MS know that much about it but we have been told that its basically a bunch of C# windows tools to ease development and some C++ modules that run on the target platform. The C++ modules are multi-threaded to get the best out of multi-core PC and Xenon CPU.
It seems to me that its 'just' normal middleware rather than a JDK style enviroment. Either way its a good thing that should help make better games
One thing that has been quoted wrong by lots of sites is the 80% figure, MS meant they hope 80% of the boiler plate code (low-level engine stuff) could be replaced via XNA not as many sites (included this one) 80% of all code. I suspect the 80% is a bit optimisitic as well....
Vince said:
Increasingly sound operation are moving from simple operation to much more complex work. A good example is the DTS code on PS2, the PS2 was never designed to do real-time multi-channel digital sound output but by using a 'general' CPU it got that capability half-way through its life.
CPU's can be made very DSP like, by adding those capability to the CPU you can share the gates between 3D graphics and 3D sound.
If Sony with Cell has a fixed function DSP (apart from backwards capability), then they have clearly gone mad. If there is one thing an APU should do really well its as a really good programmable audio chip.
No one else thinks that the removal of the "art asset" is a mistake? Wasn't there a thread denouncing it once the initial Xenon specs. were revealed? Or after this aspect was known to be in absentia? This appears to me to be opening the floodgates to similar or identical looking aspects of shovelware. IIRC, doesn't the GC excel at producing repeated textures moreso than any other system? Allard seems to be masking it with a simplistic brick wall analogy, but the art aspect is much more comprehensive than what he leads you to believe. And without memory segmentation, or a minimal dedicated audio amount, the tradeoffs will be moreso than even in the current X-Box model.
And correct me if I'm wrong, the only way the PS2 can acheive 5.1 is due to the shared usage of the DVD component that supports it. Whereas standalone it could not. Just as the GC wasn't built to support DPLII & DPLIIx, but extensions made to the Musy-X toolkit by Factor 5 allowed for this, not exploitation of the general CPU's power.
Fafalada said:
Could the SPU do DPLII(x), you think? SNES sound DSP could do DPL after all, and it is less advanced than the SPU...
David_South#1
Banned
I didn't read this thread too closely.
I saw some mentioning of XNA though, so maybe I can help.
The system that J. Allard had at E3 running the "Car Crash Demo" & is also being used by XNA Developers, Is an Apple G5 dual-processor PC with an ATI R420 graphics card.
MS XNA is using a recompiled Windows NT kernal.
These PPC 970, ATI R420 workstations are The Standard for XNA Development.
I saw some mentioning of XNA though, so maybe I can help.
The system that J. Allard had at E3 running the "Car Crash Demo" & is also being used by XNA Developers, Is an Apple G5 dual-processor PC with an ATI R420 graphics card.
MS XNA is using a recompiled Windows NT kernal.
These PPC 970, ATI R420 workstations are The Standard for XNA Development.
whql said:
Um What I actually said is that fixed functionality is bad when applied to tasks whose resource bound is arbitrarily high or increases arbitrarily based on the given situation - which is why many parts of the rasterization pipeline that are dependant upon static bounds (say output pixels on a screen) should be fixed and see speed-ups.
Now, if you want to make an argument saying sound complexity can scale at a rate which is analogous to graphic computation, then that would be a valid argument. I'd still contend that it's basically fixed and would be better handeled by an independant and more fixed functional IC which doesn't use central resources due to the lesser perceived importance of sound and the limited output formats that exist.
But what you wrote above is absolutely horrid.
Guden, DPL2 is pretty much free on PS2.
Serving the latter off a CPU on steroids just makes sense - what's the point of adding yet Another programmable processor there?
Besides - Sony already did exactly this with PS2, there is NO programmable DSP hardware whatsoever, what you want to do custom you do with the two CPUs(unless you are happy with the awesome array of the one hardwired effect in SPU2, whoopee we have reverb -_-) And as evidenced by DTS library, you need more then your R3000 for certain things.
I completely agree with Deano, having in order of TFlop general purpose power, another programmable chip just for sound is borderline insane (not to mention putting a hard limit to your system sound without any good reason).
And what happened to being happy about sticking to one ISA across the board?
Vince, I'd vager that XB2 won't be much different from XB1 in this respect - you'll have fixed hw to serve stuff like your encoding/decoding etc. needs, and a programmable part.Vince said:
Serving the latter off a CPU on steroids just makes sense - what's the point of adding yet Another programmable processor there?
Besides - Sony already did exactly this with PS2, there is NO programmable DSP hardware whatsoever, what you want to do custom you do with the two CPUs(unless you are happy with the awesome array of the one hardwired effect in SPU2, whoopee we have reverb -_-) And as evidenced by DTS library, you need more then your R3000 for certain things.
I completely agree with Deano, having in order of TFlop general purpose power, another programmable chip just for sound is borderline insane (not to mention putting a hard limit to your system sound without any good reason).
And what happened to being happy about sticking to one ISA across the board?
