Xbox One (Durango) Technical hardware investigation

That's a possibility, (32 MBs at 6T per bit is ~1.5 B transistors), although I contend that nVidia would go with lower power for the same performance if it was an option, certainly in the supercomputing space where power consumption is a massive decision making factor to minimise expensive running costs. Have we any confirmation that it's 6T SRAM though? I'm getting lost on what current knowledge is!

 

What's the difference, if the endpoint is the same result?

 

Excuse my irruption in this chat, but I´ve been wondering if this eDRAM 3D 32 nm from IBM could be the "ESRAM" showed by VGL, according this note:

http://semiaccurate.com/2013/02/07/ibm-adds-5-dimensions-to-chip-stacks-in-one-year/#.URztjeGFBdg

This eDRAM 3D was mentioned in this other press note from IBM in early 2012:

http://www-03.ibm.com/press/us/en/pressrelease/36465.wss

And casually this eDRAM 3D has beed rumored in the manufacture of the next xbox by IBM and GlogalFoundry:

http://www.xbitlabs.com/news/multim..._Produce_Chips_for_Next_Gen_Xbox_Rumours.html

I apologize myself for this little deviation of this topic, but your debate is very interesting so I couln´t resist put this possibility in the table

 

If the GPU keeps switching tasks or your data set is small, then you may need to fetch new ones from the RAM and incur latency cost for fetching new chunks of data. If the GPU runs a predictable set of algorithms, it should be possible to hide most of the latencies. In which case, the bandwidth would be more important to sustain your compute nodes.

The developers will try to optimize for the architectures. e.g., Cell LocalStore has 6 cycle latency compared to tens and hundreds elsewhere. It completes MLAA in 5ms over 5 SPUs @ 3.2 GHz. A powerful PC GPU completes a variant of MLAA (less accurate) in 0.1ms despite the longer latency to access its cache and RAM. The devs were able to hide the GPU's latency, and churn through MLAA using all its nodes quickly.

To make sure the CUs are used efficiently for both GPGPU and normal graphics work, AMD advices separating the work. This is probably why Orbis splits its CUs into 14+4 combo. It will help the GPU to be more efficient overall.

On Durango, the shorter latency to hit ESRAM will give it more efficiency when switching work, assuming it doesn't split its CUs up. It's another way to deal with the same problem.

 

I like best cases scenarios to,that doesn't mean i will think that durango will perform even close to a GPU that far far surpass it.

Durango like any other GPU have its limits,ESRAM at best case scenario can help the 7770 achieve its peak,not go over that peak,no matter what some people try to paint this the 7770 peak is far far away from the 680GTX peak.

I am sure when all is say and done Durango will not be even close to that GPU,with all its efficiencies.

 

All right. Let me present a plausible and not uselessly favorable-to-Durango scenario.

If you measure the average processing performance of Durango's GPU while running an optimized multiplatform game vs. that of a 680 GTX while running the PC version of that same game with all of the architectural limitations of the software and hardware that make up the PC platform, how might they compare?

 

I said this in another thread ( i think) but when you are comparing whats in Durango to what is in a whole line of consumer GPUs, doesn't the solution have to be scaleable to all price points? Sure you could build a $600 680GTX with ESRAM but it would be a one off solution in a whole family of graphics that need to hit prices as low as $150. They cant build a high end card, swap out a slower/cheaper memory bus, and chop off CUs to make cheaper versions if relatively high-cost ESRAM is at the heart of the design right?

EDIT: I'm not making performance claims one way or the other, just trying to answer the "why its in Durango and not in Kepler" question.

 

The game in my proposed scenario would be developed for next-gen console platforms (Durango & Orbis) and PC.

 

The console version will punch above their weight because developers will optimize the same software better. Plus they have low level access to the GPU. All these latency and bandwidth benefits require developer intervention.

 

There are plenty of reasons to feature UberSRAM in Keplar, but I'm looking squarely at Tesla.

 

Durango rumours are saying devs haven't got low-level access.

 

Well, perhaps a lower level API than DirectX ?

I also think that workflow is more important this gen because the consoles are rather similar. Any chance we will see heavily baked assets and precalculated data for Durango's 8GB memory ?

 

Who said that?

 

The difference is that usually the result are not the same. You have a far greater chance at achieving your goal if you plan for something from the very beginning than coming up with late "hacks" to improve a system's performance.

 

Is 7770 confirmed?