Xbox2 graphics 10 times higher geometry perf. than X800 XT ?

we had 4 pipes, then 8, then 16 (did we had 8 actually..?!)

well, each new hw gen from the last times doubled or quadrupled pipeline count. r5xx ones are the next episode => another doubling or quadrupling should come.

so up to 64 are easily doable. SLI on console.. dunno.. console-SLI'ing would be more fun (plug two xbox 2 together for ultrahighresgaming :D)
 
Unknown Soldier said:
(although Nvidia stated 8).
US

Did they? I thought they stated :oops: !!


On topic:
So if the XGPU2 can arbitrarily use its units for either vertex or pixel shading, does that mean it's more of a DX10 part (where vertex and pixel shaders will supposedly be sharing the same units)? Cause i'm not sure you can do that with DX9, i'm open to explanations..... :oops:
 
london-boy said:
So if the XGPU2 can arbitrarily use its units for either vertex or pixel shading, does that mean it's more of a DX10 part (where vertex and pixel shaders will supposedly be sharing the same units)? Cause i'm not sure you can do that with DX9, i'm open to explanations..... :oops:
That's actually more up to driver though an ability to control ALU allocation from API is surely may be handy for programmers.

As i see it, R500 is a DX9+ part. Or DX9.5 if you wish.
 
DegustatoR said:
london-boy said:
So if the XGPU2 can arbitrarily use its units for either vertex or pixel shading, does that mean it's more of a DX10 part (where vertex and pixel shaders will supposedly be sharing the same units)? Cause i'm not sure you can do that with DX9, i'm open to explanations..... :oops:
That's actually more up to driver though an ability to control ALU allocation from API is surely may be handy for programmers.

As i see it, R500 is a DX9+ part. Or DX9.5 if you wish.

But today it is not possible at all, be it because of drivers or DX9. While it will be "standard" on DX10. Right? :|
 
london-boy said:
So if the XGPU2 can arbitrarily use its units for either vertex or pixel shading, does that mean it's more of a DX10 part (where vertex and pixel shaders will supposedly be sharing the same units)? Cause i'm not sure you can do that with DX9, i'm open to explanations..... :oops:

Nothing actually prevents this now, likewise nothing prevents you from having separate VS/PS/GS under D3D10.0, however its a case of when its sensible to do these things under the target API. Presently, although VS/PS3.0 are close in terms of capabilites, they don't have the same instruction set/capabilites so there is an argument that there may be some waste if you unified under DX9, but technically it can be done. Likewise, because DX10 does have the same technical specifications / capabilities for VS/PS then logically that would be the most opportune time to move to unified hardware on the PC.

As with XBox1 and its extra capabilities, XBox2 isn't targetting any single specific API so it can target more than "just" SM3.0 whilst not necessarily being "SM4.0" and these will be exposed for the console. My expectation is that Xenon graphics will fall close to the D3D10.0 specifications as they are now but still have some arbitary limitations that wlould prevent it from being full D3D10.0.
 
DaveBaumann said:
london-boy said:
So if the XGPU2 can arbitrarily use its units for either vertex or pixel shading, does that mean it's more of a DX10 part (where vertex and pixel shaders will supposedly be sharing the same units)? Cause i'm not sure you can do that with DX9, i'm open to explanations..... :oops:

Nothing actually prevents this now, likewise nothing prevents you from having separate VS/PS/GS under D3D10.0, however its a case of when its sensible to do these things under the target API. Presently, although VS/PS3.0 are close in terms of capabilites, they don't have the same instruction set/capabilites so there is an argument that there may be some waste if you unified under DX9, but technically it can be done. Likewise, because DX10 does have the same technical specifications / capabilities for VS/PS then logically that would be the most opportune time to move to unified hardware on the PC.

As with XBox1 and its extra capabilities, XBox2 isn't targetting any single specific API so it can target more than "just" SM3.0 whilst not necessarily being "SM4.0" and these will be exposed for the console. My expectation is that Xenon graphics will fall close to the D3D10.0 specifications as they are now but still have some arbitary limitations that wlould prevent it from being full D3D10.0.

Thanks! That explains a lot.
 
jvd said:
I dunno about that. I think with the dreamcast that was offical over with. Mabye even the nintendo 64.
Not at all - in terms of general purpose processing, the current generation of consoles has barely met the requirements of entry level PC cpus when they came out.

If we use analogy relative to PC, DC would have a 700Mhz SH4, or PS2 a 1Ghz R5900, to be more like Xenon's cpu in 2005.
 
DegustatoR said:
london-boy said:
So if the XGPU2 can arbitrarily use its units for either vertex or pixel shading, does that mean it's more of a DX10 part (where vertex and pixel shaders will supposedly be sharing the same units)? Cause i'm not sure you can do that with DX9, i'm open to explanations..... :oops:
That's actually more up to driver though an ability to control ALU allocation from API is surely may be handy for programmers.

As i see it, R500 is a DX9+ part. Or DX9.5 if you wish.

ATI have stated (in Richard Huddys 'save the nanosecond' video presentation at GDC 2004) that the allocation of the unified ALUs would be controled by the hardware (silicon) he said won't be the driver and definitely not the application that controls the allocation.
 
PeterAce said:
ATI have stated (in Richard Huddys 'save the nanosecond' video presentation at GDC 2004) that the allocation of the unified ALUs would be controled by the hardware (silicon) he said won't be the driver and definitely not the application that controls the allocation.
What he sad and what will be aren't necessary the same thing. Remember that not only ATI is working on DX10 specs.
 
DX10 specs won't really make any difference as to how you implement the control of the units. Like I said, there should be nothing to stop IHV's going down the route of explicitly creating the shader pipeline in the traditional fashion or in a unfied fashion (indeed, if David Kirks comments to me earlier this year still hold true now, then I would suggest that NVIDIA may still be looking at the former route). If you do implement a unified shader structure how the control of the hardware resources is achieved is nothing to do with the API (just as it isn't when you have a traditional pipeline).
 
DaveBaumann said:
DX10 specs won't really make any difference as to how you implement the control of the units. Like I said, there should be nothing to stop IHV's going down the route of explicitly creating the shader pipeline in the traditional fashion or in a unfied fashion (indeed, if David Kirks comments to me earlier this year still hold true now, then I would suggest that NVIDIA may still be looking at the former route). If you do implement a unified shader structure how the control of the hardware resources is achieved is nothing to do with the API (just as it isn't when you have a traditional pipeline).
You have control of the hardware recources in the API even now. Unified shader ALUs is just another step in the flexibility of the pipelines. So if you make them flexible, you might want to give users the ability to control it.
 
So why is this not done today, if it's feasible? It sounds like under certain circumstances it would yield major performance jumps...
 
london-boy said:
So why is this not done today, if it's feasible? It sounds like under certain circumstances it would yield major performance jumps...

DaveBaumann has already explained why :
DaveBaumann said:
Presently, although VS/PS3.0 are close in terms of capabilites, they don't have the same instruction set/capabilites so there is an argument that there may be some waste if you unified under DX9, but technically it can be done.
 
You have control of the hardware recources in the API even now.

You don't have any significant controls over how the processing occurs - this is primarily dictated by resource limitations.

Unified shader ALUs is just another step in the flexibility of the pipelines. So if you make them flexible, you might want to give users the ability to control it.

Not really - this is up to the hardware to decide dependant on the loads put upon it; at present this is implicit in the fixed limitations between VS and PS, but that should also remain under a unfied structure. Even if you did want to offer some controls over that, this wouldn't negate hardware instruction schedulers.
 
davepermen wrote:
having today 16 + 6 shader units (or so?!), means it will double in a year possibly. will lead to theoretically 32 + 12 units. if they unify, it will be more around 32 units at all.. if you SLI then, you get 64..

it's not far away (considering 3 cpu's for the xbox.. so you could have 2 gpu's as well.. or both plugged into one, a.k.a. 64x1..).


well only if Xbox 2 is significantly delayed. as things stand now, Xbox 2 is coming out in roughly one year. the VPU for Xbox 2 has already taped out. it purportedly has 48 shader units. possibly 64 but more likely 48. which can work on either geometry or pixels.

so, todays fastest ATI hardware has 16 + 6 shader units (22 total)
yes, next year's Xbox 2 will have more than double the shader units, most likely 48 unified units.

SLI obviously doubles everything provided you have two of the same class of ATI cards. sure, I would love SLI in a console, like a new NEO GEO but it won't happen with Xbox 2.
 
Back
Top