therealskywolf
Regular
Check this http://www.anandtech.com/tradeshows/showdoc.aspx?i=2423 out guys
Xbox 360 graphics processor codenamed: XENOS. some details
- Thread starter Megadrive1988
- Start date
Megadrive1988
Veteran
wireframe said:
cool. thanks for writing this out wireframe, to help make things more clear, and making it sort of an open-ended answer - things could have changed by now, but this is how you understand it according to what was reported / announced. nice post.
pc999 said:
Heh. I just followed the link near the bottom just now and saw that Tim had written exactly what I wrote. I wasn't aware that this had already been answered, and to you, in another thread already.
This topic is obvioulsy hot, but I still caution everyone to be careful in comparing these metrics. The ATI unit has more flexibility in terms of pixel/vertex ops as these are a shared resource (a la SM 4.0, although I am not sure why an SM spec would specify how these ops are internally scheduled and executed) than the RSX, which, so far, is assumed to be of a more classically seperated pixel/vertex design. Given Nvidia's 136 ops per cycle, we can imagine that there are cycles where not all pixel shader units are needed and too few vertex units are available. For R500 this would present a situation where it can "switch" its operation and find some optimal balance. However (and this is probably a huge however), it can't be easy to decide what that optimal balance is and schedule it. If you wasted a whole cycle determining what the optimal distribution is you lost all your 96 op oportunities (this is just an example in the extreme).
I am probably not thiking correctly about this, but I really don't get why MS/ATI would want this type of GPU in the Xbox. I could understand the benefit better of this type of pooled resource when the target is not known, allowing the hardware to adapt itself to new software needs. But with a console you have everything known and you should be programming it to the metal to get peak performance so even if the pixel and vertex logic units are separated, you could optimize and work around any limitations this may impose.
The same goes for the CPUs in these boxes. The Cell is something like NetBurst (Pentium 4) taken to an extreme. This should not pose a problem, however, because this is known and developers can optimize for this as the whole system is built around this architecture.
If anything, I think perhaps the best thing to look at for IQ/performance between these machines is the FSAA ability. It looks like the Xbox 360 has an advantage here, getting 4x FSAA "for free". I say this is an advantage because it may be unlikely that developers will be willing to put that much more into making a "better" PS3 version of a game, with any asset change this may imply, unless the result will be very noticeable. So, I suspect that many games that come on both platforms will look the same, but the Xbox 360 may have an advantage with FSAA then.
Megadrive1988 said:
No problem. I could probably better prove the case simply by saying "ATI claims two ops per clock"...so explain to me how you can get anything more that 96 ops out of 48 logic units? You can't have it both ways. 96 billion ops per second (given 500MHz clock) would imply 4 ops per logic unit per clock or 96 logic units doing two ops per clock (which is the ATI statement and I think we can assume this one is correct as it jives with the original numbers).
The 96 was obviously misplaced when it got a "billion ops per second" behind it when it should have just been "per clock".
Jawed
Legend
There are two times when the execution time of a shader instruction is not known:
1. texturing (depends on filtering and cache status)
2. branching (will branch prediction fail?)
When a thread requires texturing, the thread is put into the texturing queue. The GPU knows that a texturing operation is coming along, so it can fill the ALU pipeline with a new thread which will start to execute immediately that the texturing operation causes the old thread to switch out.
When a thread's branch prediction fails, the thread is put back into the execution queue (and the execution pipeline needs to flush out the superfluous instructions). The GPU will have already scheduled another thread to follow behind the superfluous instructions. The shorter the pipeline, the less cycles are wasted.
So, in general, the GPU knows precisely what the balance of TMU and ALU operations is, and it can easily allocate threads as these resources become available. Because of pipelining, these resources never go idle (except for a branch prediction failure).
Addtionally the GPU can split threads into clauses, e.g. of a maximum of 4 instructions. This increases the granularity of execution, increasing the rate at which short threads are completed, which in turn means that the queueing system doesn't get blocked up with threads dependent on texturing.
The upshot of all this should be that R500 runs every resource (ALU and TMU) at close to 100% utilisation, i.e. the peak-rate is real world.
The next interesting question is whether R500 arranges "pipelines" as quads, or separates texture caches or command thread queues into quads...
Jawed
1. texturing (depends on filtering and cache status)
2. branching (will branch prediction fail?)
When a thread requires texturing, the thread is put into the texturing queue. The GPU knows that a texturing operation is coming along, so it can fill the ALU pipeline with a new thread which will start to execute immediately that the texturing operation causes the old thread to switch out.
When a thread's branch prediction fails, the thread is put back into the execution queue (and the execution pipeline needs to flush out the superfluous instructions). The GPU will have already scheduled another thread to follow behind the superfluous instructions. The shorter the pipeline, the less cycles are wasted.
So, in general, the GPU knows precisely what the balance of TMU and ALU operations is, and it can easily allocate threads as these resources become available. Because of pipelining, these resources never go idle (except for a branch prediction failure).
Addtionally the GPU can split threads into clauses, e.g. of a maximum of 4 instructions. This increases the granularity of execution, increasing the rate at which short threads are completed, which in turn means that the queueing system doesn't get blocked up with threads dependent on texturing.
The upshot of all this should be that R500 runs every resource (ALU and TMU) at close to 100% utilisation, i.e. the peak-rate is real world.
The next interesting question is whether R500 arranges "pipelines" as quads, or separates texture caches or command thread queues into quads...
Jawed
DerekBaker
Newcomer
wireframe said:
'On chip, the shaders are organized in three SIMD engines with 16 processors per unit, for a total of 48 shaders. Each of these shaders is comprised of four [my bold] ALUs that can execute a single operation per cycle, so that each shader unit can execute four floating-point ops per cycle.'
http://techreport.com/etc/2005q2/xbox360-gpu/index.x?pg=1
What's even worse, they're not only using bits instead of bytes, but they're counting in compression as well. The actual transfer rate is 32GB/s, not 256.Tim said:
Sad to see the people at hardocp just swallowing these numbers like a bunch of nooblars, but hey, this is what happens when technical stuff is 'explained in plain english'. Meaning, it's some PR fuck lying his head off to make things sound more impressive than they actually are.
Luminescent
Veteran
Could it be that ATI claims 48 billion ops per second because each of R500's 48 units can co-issue a vec3 and scalar?
This would seem to be limited to cases where all units are dedicated to pixel processing because vertex ops require vec4, which would use-up the unit that would otherwise be dedicated to scalar ops.
This would seem to be limited to cases where all units are dedicated to pixel processing because vertex ops require vec4, which would use-up the unit that would otherwise be dedicated to scalar ops.
Luminescent
Veteran
But since Dave is a perfectionist; it may be quite a while till we get an article. 
