"4xAA": Microsofts big mistake.

Status
Not open for further replies.
wco81 said:
Won't console games have frame rates locked at 30 or 60?

IOW, you're not going to have an X360 game at 100 FPS while the PS3 version is at 50 FPS or vice versa.

If AA and all the other filtering prevents a game from hitting 30 or 60 FPS, the developer will turn off those detail-enhancing features.

Or, maybe one version will run at 60 FPS while the other version will run at 30 FPS but both will have comparable AA and HDR?

Assuming all else in the systems, total, were equal, sure (though not all console games have their framerate locked, I don't think).

But relative framerate between the consoles is going to be impacted by more than AA or HDR. It'd really all depend on your game.
 
This is another "my daddy is stronger than your daddy" type of thread, and hence rather stupid, and I hereby award it this emoticon:


:rolleyes:
 
X360: XeCPU + Xenos bandwidth available externally

~ (22.4 - South Bridge B/W) GB/sec*


PC: CPU + G70 bandwidth available externally

~ (38.4 + PCI-E - South Bridge B/W - Backbuffer B/W ) GB/sec


PS3: CELL + RSX bandwidth available externally

~ (48 - Backbuffer B/W) GB/sec**


* Xenos 32 GB/sec to EDRAM module (256 GB/sec internal) includes backbuffer B/W that doesn't need to access 'external' RAM. However, for fair comparison, this is deducted from external B/W for PC and PS3 which have to absorb the bandwidth cost for the backbuffer to/from external system RAM. The South Bidge B/W is shared with UMA memory B/W of 22.4 GB/sec alongside the CPU+GPU.

** 48 GB/sec ~ 22.4 GDDR3 + 25.6 XDR RAM. Also PS3 has a dedicated 5 GB/sec read/write South Bridge B/W.

To clarify RSX peak read/write IS ~ 57.4 GB/sec (35 + 22.4). This is read/write for GDDR3 + FlexIO (not XDR). CELL has 'internal' bandwidth like Xenos has internal B/W of 256 GB/sec to eDRAM within the EDRAM module. The EIB ring bus within CELL can read/write data from PPE L2 cache + SPE local stores and this can feed RSX via the FlexIO. Imagine CELL + RSX as a 'single' chip passing data 'internally'. Siimilar to Xenos + EDRAM module passing data 'internally' as a 'single' chip.

The backbuffer B/W is predictable for Xenos but for PS3/PC it's variable. Here's a discussion on estimates and worse case scenarios for the backbuffer,

http://www.beyond3d.com/forum/viewtopic.php?t=24149
http://www.beyond3d.com/forum/viewtopic.php?p=554263#554263

And anyone who claims anything is free, should always claim 'essentially for free'. The 'essentially' prefix usually means there IS a cost somewhere else. What that cost is can be measured in different ways. But in a sense, I agree with Brimstone that all parties concerned are collectively marketing their consoles... some more efffectively than others...


EDIT: Typos for PC...

EDIT 2: X360 South Bridge B/W was not shared as UMA and removed.

EDIT 3: Nope! X360 South Bridge B/W is shared with 22.4 GB/sec UMA!

http://www.beyond3d.com/articles/xenos/index.php?p=03

@ Dave, that diagram is mis-leading at first glance! ;)
 
I disagree with the original post. I think it was a smart decision for Microsoft to use an embedded memory approach and provide anti-aliasing in every game, mandatory.


I think it is a mistake for PS3 GPU to not have eDRAM, and now PS3 is going to suffer from some of the same problems that Xbox1 suffered by not having an extremely high-bandwidth bus. the problem will not be as bad as Xbox1 since RSX has its own bus to GDDR3 memory, but the bandwidth is not all that high since it is 128-bit. the Xbox360 can get away with its low-bandwidth shared main memory bus because much of the strain is allieviated by the higher-bandwidth busses from GPU parent die to daughter die and especially from eDRAM to logic within the daughter die.

this is going to give Xbox 360 a real advantage over PS3 in this area, which will help to counter some of the advantages that PS3 has over Xbox 360.
 
Megadrive1988 said:
I disagree with the original post. I think it was a smart decision for Microsoft to use an embedded memory approach and provide anti-aliasing in every game, mandatory.


Where did I imply eDRAM was a mistake? The marketing of the second core with eDRAM and how the Xenos is much more capable with regards to A.A. is what this thread is about. MS and ATI haven't done a good job explaining this aspect.

A.A. by RSX won't be the same quality as what Xenos provides.
 
Jaws said:
Brimstone said:
...
A.A. by RSX won't be the same quality as what Xenos provides.

So what are the differences with RSX AA and Xenos AA then?

The RSX won't have the bandwidth. If A.A. is turned on, there will be a GPU performance hit forcing a tradeoff elsewhere. Also if the RSX follows the path of the G70, if the game uses HDR, and you want AA you've got a problem.
 
Though possibly true, I hope you realize that's all unconfirmed and conjectural. We don't know what differences there are between RSX and G70 and shouldn't get ahead of ourselves with claims of x is better than y when we haven't the technical details of x.
 
Brimstone said:
Jaws said:
Brimstone said:
...
A.A. by RSX won't be the same quality as what Xenos provides.

So what are the differences with RSX AA and Xenos AA then?

The RSX won't have the bandwidth. If A.A. is turned on, there will be a GPU performance hit forcing a tradeoff elsewhere. Also if the RSX follows the path of the G70, if the game uses HDR, and you want AA you've got a problem.

Well, everything is a balance. If AA causes a cost in performace elsewhere for RSX, then that will be under the control of devs, especially in a closed console environment. The AA setup has 'already' caused a performace hit elsewhere in transistor costs for Xenos...

The bandwidth for RSX is not as limited at first glance. It has 57 GB/sec read|write available to it from GDDR + FlexIO. And my above link shows 720P, 4xSSAA, 64bit HDR ~ 12-25 GB/sec for extreme cases, which is well within it's reach.

G70 currently cannot do MSAA + HDR but is still capable of SSAA + HDR. Whatever AA RSX inherits from G70 and whatever differences there are, the magnitude of the performance hit still remains to be seen but it's a 'choice' given to devs on where they spend the resources...
 
The bandwidth for RSX is not as limited at first glance. It has 57 GB/sec read|write available to it from GDDR + FlexIO. And my above link shows 720P, 4xSSAA, 64bit HDR ~ 12-25 GB/sec for extreme cases, which is well within it's reach.

Thats if the cell cpu is not used for anything. Which i think we all know is bs .
 
jvd said:
The bandwidth for RSX is not as limited at first glance. It has 57 GB/sec read|write available to it from GDDR + FlexIO. And my above link shows 720P, 4xSSAA, 64bit HDR ~ 12-25 GB/sec for extreme cases, which is well within it's reach.

Thats if the cell cpu is not used for anything. Which i think we all know is bs .
FlexIO bw is the same whether Cell is used or not. The bw is bi-directional. RSX can write 20GB/s and read 15GB/s. Or I might have that backwards, but it doesn't matter what Cell is doing, that bandwidth is between the XDR and the PPE/SPE-farm. RSX connects to the EIB, so it can theoretically have all of that to itself without touching XDR at all.

If you're just harping on semantics, then duh. There's almost no such thing as 100%. That bw won't be available all the time, but as Jaws pointed out, even in a bad-case scenario, RSX should still have bw to work with. PEACE.
 
it doesn't matter about the connection between the rsx and cell. The xdr will never transfer faster than its designed too. So if the cell uses the xdr ram it will take away that bandwidth . So if it uses 10gb/s of the 24gb/s (?) the cell has . The rsx can only acess the xdr ram at 14gb/s for that second .

The flex io isn't a magical device that will stop that from happening .
 
jvd said:
The bandwidth for RSX is not as limited at first glance. It has 57 GB/sec read|write available to it from GDDR + FlexIO. And my above link shows 720P, 4xSSAA, 64bit HDR ~ 12-25 GB/sec for extreme cases, which is well within it's reach.

Thats if the cell cpu is not used for anything. Which i think we all know is bs .

Excluding the backbuffer, that's the same as saying Xenos has access to 22.4 GB/sec system RAM and XeCPU doesn't do anything else...

I've already explained above the bandwidth of RSX is to FlexIO + GDDR3 ~ 57 GB/sec. The EIB ring bus within CELL can pass data to RSX...e.g. procedurally generate data without flooding XDR as an example...

The EIB ring bus has 96 bytes/cycle bandwidth. If it's clocked at half, 1.6 Ghz, that's ~ 153 GB/sec or 306 GB/sec at full speed B/W. The PPE L2 cache and 7 SPE's are on that EIB ring bus. Just because RSX accesses FlexIO, doesn't mean that XDR is accesed. The data to/from the EIB is passing to/from FlexIO and can bypass XDR...
 
Excluding the backbuffer, that's the same as saying Xenos has access to 22.4 GB/sec system RAM and XeCPU doesn't do anything else...
but who is claiming that ?

The same 22.4gb/sec bandwidth will be shared between the gpu and ram on the x360 .

I've already explained above the bandwidth of RSX is to FlexIO + GDDR3 ~ 57 GB/sec. The EIB ring bus within CELL can pass data to RSX...e.g. procedurally generate data without flooding XDR as an example...
And how will that work ? If you want to use the cell the local caches are going to be needed for the cpu tasks . Not only that but your still going to be limited by the xdr ram not the flexio bus to the rsx if you want ot use any sizable amount of that ram .

The EIB ring bus has 96 bytes/cycle bandwidth. If it's clocked at half, 1.6 Ghz, that's ~ 153 GB/sec or 306 GB/sec at full speed B/W. The PPE L2 cache and 7 SPE's are on that EIB ring bus. Just because RSX accesses FlexIO, doesn't mean that XDR is accesed. The data to/from the EIB is passing to/from FlexIO and can bypass XDR...
and now your assuming that cell wont be using its own cache to do tasks needed .



The comparisons are fool hardy as your not accounting for the xbox360s hardrive , which can be used for cache . If we want to throw useless numbers in lets throw that in too
 
jvd said:
Excluding the backbuffer, that's the same as saying Xenos has access to 22.4 GB/sec system RAM and XeCPU doesn't do anything else...
but who is claiming that ?

You are by your reasoning with RSX...

XeXPU + Xenos do not work in the same way as CELL + RSX.

X360 is UMA and PS3 is NUMA.

jvd said:
I've already explained above the bandwidth of RSX is to FlexIO + GDDR3 ~ 57 GB/sec. The EIB ring bus within CELL can pass data to RSX...e.g. procedurally generate data without flooding XDR as an example...
And how will that work ? If you want to use the cell the local caches are going to be needed for the cpu tasks . Not only that but your still going to be limited by the xdr ram not the flexio bus to the rsx if you want ot use any sizable amount of that ram .

The easiest way to explain it is this....inside CELL theres a ring, like a mini ring network...on this ring are 7 SPE's and a L2 cache. These SPE's can work with their local memories and access the L2 cache without accessing XDR ideally (but there maybe cache misses)...now think of RSX as being the 8th SPE on that ring bus...it can still work without accessing the XDR. But if there are cache misses, then of course XDR will be accesed or even GDDR3...

jvd said:
The EIB ring bus has 96 bytes/cycle bandwidth. If it's clocked at half, 1.6 Ghz, that's ~ 153 GB/sec or 306 GB/sec at full speed B/W. The PPE L2 cache and 7 SPE's are on that EIB ring bus. Just because RSX accesses FlexIO, doesn't mean that XDR is accesed. The data to/from the EIB is passing to/from FlexIO and can bypass XDR...
and now your assuming that cell wont be using its own cache to do tasks needed .

See above....

jvd said:
The comparisons are fool hardy as your not accounting for the xbox360s hardrive , which can be used for cache . If we want to throw useless numbers in lets throw that in too

Seriously, you do not seem to understand CELL or it's NUMA config...you even admitted this in another thread...do not be so flippant if you do not understand what's being discussed.
 
easiest way to explain it is this....inside CELL theres a ring, like a mini ring network...on this ring are 7 SPE's and a L2 cache. These SPE's can work with their local memories and access the L2 cache without accessing XDR ideally (but there maybe cache misses)...now think of RSX as being the 8th SPE on that ring bus...it can still work without accessing the XDR. But if there are cache misses, then of course XDR will be accesed or even GDDR3...

but the size of the cache isn't sizable enough to do much of anything . Not to mention that the cache will be filled with the data needed for the spe's to do thier task



Seriously, you do not seem to understand CELL or it's NUMA config...you even admitted this in another thread...do not be so flippant if you do not understand what's being discussed.

I understand enough to know that the rsx will never see that 58GB/s your claiming and that its a bs claim . As I siad why not add the hardrive in the x360 to the xeno's ram supply and bandwidth .
 
jvd said:
but the size of the cache isn't sizable enough to do much of anything . Not to mention that the cache will be filled with the data needed for the spe's to do thier task

So, we're talking about bw. RSX doesn't have to touch XDR to use that FlexIO bus. It can work with the SPEs alone. Even if it's not enough space in that 256k, what if you're running some recursive task that reads and writes lots of small chunks of data to and from the SPEs? Then you're maximizing that 35GB/s without touching the XDR. This is a theoretical, but just to show that the bw figure given is real.

I understand enough to know that the rsx will never see that 58GB/s your claiming and that its a bs claim . As I siad why not add the hardrive in the x360 to the xeno's ram supply and bandwidth .

Huh? What are you getting at? The bw figures in the 360 should be given the same scrutiny then. Hell, everything gets the same scrutiny. There is no such thing as 100% util. As Jaws said, are you gonna poo-poo the Xenos bandwidth to UMA too, b/c once the XeCPU starts making accesses, "we know that 22GB/s figure is bs." How about that 32GB/s and free 4xMSAA? Once you start tiling, that bandwidth figure goes down. I guess that figure is bs too, right? :rolleyes: You see my point? And please don't tell me I'm reading you wrong, b/c I'm not. That copout won't work this time. PEACE.
 
jvd said:
easiest way to explain it is this....inside CELL theres a ring, like a mini ring network...on this ring are 7 SPE's and a L2 cache. These SPE's can work with their local memories and access the L2 cache without accessing XDR ideally (but there maybe cache misses)...now think of RSX as being the 8th SPE on that ring bus...it can still work without accessing the XDR. But if there are cache misses, then of course XDR will be accesed or even GDDR3...

but the size of the cache isn't sizable enough to do much of anything . Not to mention that the cache will be filled with the data needed for the spe's to do thier task

We are talking about available bandwidths not size of caches. Think about this...the current redundant 8th SPE could consume more bandwidth if activated than what RSX is demanding on the EIB ring bus...


jvd said:
Seriously, you do not seem to understand CELL or it's NUMA config...you even admitted this in another thread...do not be so flippant if you do not understand what's being discussed.

I understand enough to know that the rsx will never see that 58GB/s your claiming and that its a bs claim . As I siad why not add the hardrive in the x360 to the xeno's ram supply and bandwidth .

No you don't understand. If you did, you wouldn't have asked what the X360's hard disk has got anything to do with what we're discussing...

We're discussing RAM bandwidths and data flows connected to CPU/GPU on die memory controllers...not hard disk virtual memory which doesn't alter these available bandwidths.

That RSX 57 GB/sec read|write is as real as Xenos 54 GB/sec read|write (22.4 system + 32 to EDRAM module). However, in X360's case, the XeCPU under those conditions cannot access system RAM but CELL can still access system RAM (XDR).
 
Status
Not open for further replies.
Back
Top