NGGP: NextGen Garbage Pile (aka: No one reads the topics or stays on topic) *spawn*

[AstoundingHolmes]

It's ~170 GB/s vs ~170 GB/s. The division in Durango's BW between RAM pools doesn't negate the working BW the processors have available. And if Durango has a clever architecture of lower latency RAM that enables better efficiency, it could come out on top. Of course, that would require considering these boxes are more than just a collection of numbers that can be compared as bigger=better...

However, all bandwidth usage is not the same, and some processes use far more in comparison to others, like render target buffers or shadow maps, so depending on how that bandwidth is allocated it may not be fair to equate the two. For instance, if we are to believe ageis, the ROPs in Durango are not tied to the eSRAM, and since ROP processes account for a large chunk of bandwidth usage developers may feel more constrained sharing that bandwidth usage along with everything else with only ~70GB/s available.

 

[Arwin]

Exactly. But all this just stresses the prematurity of the whole discussion.

We can only hope that GDC reveals some stuff. Above all though, I am hoping that both consoles will launch this Christmas. I know that is overly optimistic, but from all we've seen so far, there is one thing that stands out: it should be extremely easy to develop a game on PC now and then get it to work on either of the two consoles later. Sure, a lot of optimisation work can then still be done, but it's certainly possible.

But even that is pure speculation, and until E3 has passed, we won't know anything. But it seems fair to assume that both consoles will be presented to the public by then.

 

[Xenio]

However, all bandwidth usage is not the same, and some processes use far more in comparison to others, like render target buffers or shadow maps, so depending on how that bandwidth is allocated it may not be fair to equate the two. For instance, if we are to believe ageis, the ROPs in Durango are not tied to the eSRAM, and since ROP processes account for a large chunk of bandwidth usage developers may feel more constrained sharing that bandwidth usage along with everything else with only ~70GB/s available.

even if between ROPS and eSRAM we have a DME, this does not means they don't target eSRAM, and the low latencies of the system could be a big advantage over gddr, so 170 GB/s using eSRAM could be better than 170 GB/s using gddr alone

 

[Shifty Geezer]

However, all bandwidth usage is not the same, and some processes use far more in comparison to others, like render target buffers or shadow maps, so depending on how that bandwidth is allocated it may not be fair to equate the two. For instance, if we are to believe ageis, the ROPs in Durango are not tied to the eSRAM, and since ROP processes account for a large chunk of bandwidth usage developers may feel more constrained sharing that bandwidth usage along with everything else with only ~70GB/s available.

What you're discussing here is not, 'which console is better?' but 'what are the actual specs of the consoles?' Which is precisely the point. We don't know. For someone to take 'we don't know' and conclude on the most primitive of numerical comparisons that Orbis will achieve 2x the framerate of Durango is plain stupid.

 

[Brad Grenz]

even if between ROPS and eSRAM we have a DME, this does not means they don't target eSRAM, and the low latencies of the system could be a big advantage over gddr, so 170 GB/s using eSRAM could be better than 170 GB/s using gddr alone

The fact that data must inevitably be moved between the two pools of memory make that literally, mathematically impossible.

 

[Xenio]

The fact that data must inevitably be moved between the two pools of memory make that literally, mathematically impossible.

why would you move large quantity of data between RAM and eSRAM?
anyway this is a task for DME units

but 'what are the actual specs of the consoles?' Which is precisely the point. We don't know. For someone to take 'we don't know' and conclude on the most primitive of numerical comparisons that Orbis will achieve 2x the framerate of Durango is plain stupid.

exactly

 

[Averagejoe]

I also think the 14+4 setup as well as the APU+GPU concept are just abstractions of how this Liverpool processor works. It's all a big hetereogneous processor, so I think it's better to view each element as a gear wheel instead of a complete new engine. If I were Sony I would aim to have the infamous 4 CUs as flexible as possible. Having them available for GPGPU and also for rendering would be the silver bullet. Maybe Sony says "you can use as much GPU resources for rendering as you want, but we want you to use only these four super-duper CUs for your GPGPU algorithms".

Exactly.

I don't think sony is using those 4CU for just showing off,this sounds like Cell and we know how much sony push Cell,before launch of the PS3 many were quick to downplay the SPE even MS took at jab at them naming them as useless DSP,now we know better.

I am sure that if sony put those 4CU there is for a reason,and i am sure they will be exploited to the max..

 

[Hecatoncheires]

I can understand that Vishera at 32nm is a bad choice for the example setup, but richland is 28nm, IIRC, so that may be more viable perhaps? I hadn't really thought carefully about performance at the lower end frequencies. I just assumed vishera/richland would perform better than Jaguar at even low frequencies, but I guess Jaguar is tuned to run better at lower frequencies, while vishera/richland are tuned to higher frequencies.

Richland is a 32nm APU design based on Piledriver and VLIW4. Vishera is a 32nm desktop CPU design based on Piledriver. I guess you mean the 28nm Kaveri APU based on Steamroller and GCN? The problem is that AMD delayed the Steamroller and all platforms that are based on its cores.

 

[Brad Grenz]

why would you move large quantity of data between RAM and eSRAM?
anyway this is a task for DME units

It doesn't matter which unit's job it is. If you don't have data moving in and out of the eSRAM then you aren't using it for anything and it's entire 102GBps of memory bandwidth is going completely unused. Either that, or your entire game has to fit in 32MB. That might be a fun experiment for a demo team, but not exactly a practical approach for commercial game development.

 

[DJ12]

Fine, if you know all about both systems please tell us about cpu, dme's and gpu of durango, because we know just few details

Remove all the fud about magical chips that make mountains out of molehills and you'll be about there.

 

[Xenio]

Remove all the fud about magical chips that make mountains out of molehills and you'll be about there.

interesting irony, but aside from this, why we have to trust you, are you an insider? a developer?

It doesn't matter which unit's job it is. If you don't have data moving in and out of the eSRAM then you aren't using it for anything and it's entire 102GBps of memory bandwidth is going completely unused. Either that, or your entire game has to fit in 32MB. That might be a fun experiment for a demo team, but not exactly a practical approach for commercial game development.

for example, in real world using the eSRAM, you copy framebuffer to and from ddr continuosly?

 

[assurdum]

even if between ROPS and eSRAM we have a DME, this does not means they don't target eSRAM, and the low latencies of the system could be a big advantage over gddr, so 170 GB/s using eSRAM could be better than 170 GB/s using gddr alone

What you have said sounds completely absurd to me. How? esram will never be like a 'true' whole bandwith. I'm not an expert but the superfast ram from what I know (like edram) are more limited compared to have a 'real' RAM.

 

[LightHeaven]

for example, in real world using the eSRAM, you copy framebuffer to and from ddr continuosly?

Yes? Even if unlike 360, Durango can resolve into esram, if 32mb are not enough for you framebuffer setup you would probably have to tile and move them back to the main ram so you have room left in esram for the other tiles.

And it seems that durango can now have both the cpu and gpu acessing the esram and not only the rops, so yeah, there's precedent for moving lots of data between both memories.

 

[DJ12]

interesting irony, but aside from this, why we have to trust you, are you an insider? a developer?

Nope which puts me on par with everyone else.

 

[upnorthsox]

It's ~170 GB/s vs ~170 GB/s. The division in Durango's BW between RAM pools doesn't negate the working BW the processors have available. And if Durango has a clever architecture of lower latency RAM that enables better efficiency, it could come out on top. Of course, that would require considering these boxes are more than just a collection of numbers that can be compared as bigger=better...

So now you're doing the bandwidth adder too aye............

 

[Shifty Geezer]

So now you're doing the bandwidth adder too aye............

We have no idea about the RAM setup, so it could well be that the bandwidths do just add up. Or not. TBDR rendering to tiles in eSRAM giving 110 GB/s draw and render BW. Texture from DDR3, plus everything else on that bus (Orbis's 170 GB/s won't be just graphics; there's the whole of the game and audio and IO and stuff acting on that bus too). Then again, Durango may only be able to render from ESRAM and everything has to be copied to/from DDR3, meaning 60 GB/s writing to and from ESRAM leaving on 40 GB/s rendering BW.

We Don't Know! Anyone drawing conclusions, including whether to sum the BW or not, is just making shit up.

 

[upnorthsox]

We have no idea about the RAM setup, so it could well be that the bandwidths do just add up. Or not. TBDR rendering to tiles in eSRAM giving 110 GB/s draw and render BW. Texture from DDR3, plus everything else on that bus (Orbis's 170 GB/s won't be just graphics; there's the whole of the game and audio and IO and stuff acting on that bus too). Then again, Durango may only be able to render from ESRAM and everything has to be copied to/from DDR3, meaning 60 GB/s writing to and from ESRAM leaving on 40 GB/s rendering BW.

We Don't Know! Anyone drawing conclusions, including whether to sum the BW or not, is just making shit up.

While you're adding, don't forget the 68GB for the CPU too, that gives Durango 238GB of bw!!!

I don't agree with the head in the sand defense, though I do recognize that it may be helpful for some.

 

[Nisaaru]

Richland is a 32nm APU design based on Piledriver and VLIW4. Vishera is a 32nm desktop CPU design based on Piledriver. I guess you mean the 28nm Kaveri APU based on Steamroller and GCN? The problem is that AMD delayed the Steamroller and all platforms that are based on its cores.

I've always wondered if they employ some ex. military guys to imagine their silly product code names while securing the building?

 

[Shifty Geezer]

While you're adding, don't forget the 68GB for the CPU too, that gives Durango 238GB of bw!!!

That's the shared DDR3 BW. BW is measured from ability of the RAM to deliver, and not the ability of the processors to consume.

 

[Blazkowicz]

And there's the code name for the desktop variant of Trinity, which everybody calls Trinity anyway but Trinity was a mobile code name. I seem to believe there was one name for the chip when it's on a motherboard, but everyone forgot about it.
Richland is the outlying name here, it's like a subtle message to investors that way "we are not going bankrupt, believe us"