Xbox One (Durango) Technical hardware investigation

Status
Not open for further replies.
How effectively can an early dev kit approximate all of these custom, fixed-function pieces of silicon? Wondering if current devs can really have a clear picture of performance, for better or worse, without actually having final silicon?
Easily if the devkits have more power. The API will handle the interfaces, with the DME's and other hardware functions emulated on CPU. When they get final devkit hardware, devs can refine their code based on real-world performance.

(This compared to Orbis which seems (at least to me anyway) much more straightforward and better approximated with off-the-shelf PC parts.)
Well, there'll still be a DSP and stuff potentially in there, but Sony should be able to throw together a fairly approximate box.
 
Early dev kits are probably only good for general architecture and feature testing, but it is quite impossible to fine tune performance at all.

I imagine current development should be something like this, with two versions of engines used:
- one for testing the renderer features at some pretty bad FPS
- one for building levels and gameplays, stripped of most renderer features

How they can plan for 30fps without final silicone, I have no idea.

With this being the case, how do you think developers are able to compare the performance of the two platforms? (i.e. anyone claiming "roughly equal" power, or "orbis is slightly more powerful")

edit:thanks Shifty for weighing in on my original question as well
 
We didn't really get any exact comparisons - the 'roughly equal' stuff can be deduced from the final locked specifications alone, without any hardware.

Also, final real-world performance will heavily depend on the type of engine used. If virtual texturing is a part of an engine, Durango will probably be able to get closer to Orbis, for example - at least based on what we currently know/believe. Oh and it will also require a proper port too.
 
With this being the case, how do you think developers are able to compare the performance of the two platforms? (i.e. anyone claiming "roughly equal" power, or "orbis is slightly more powerful")

edit:thanks Shifty for weighing in on my original question as well

Roughly equal can mean they have no intention of building their game to the capabilities of the individual systems but to some level that all systems can attain.
 
At one point there was a rumor that the final silicon would be GCN2, is that possibility completely gone, now that most leaks are saying GCN?
 
Relevant

jTy0RjIxFlMWe.png


He's the dude who leaked the Halo 4 vid, you know the one in the barn :p
 
At one point there was a rumor that the final silicon would be GCN2, is that possibility completely gone, now that most leaks are saying GCN?


these leaks are from documents that are a year old allegedly.

things could have changed last year...I mean the thing barely went into beta supposedly earlier last month according to the superDae...

I think it's still too soon too close the book.

But this is just my opinion.
 
No more Orbis in the Durango thread please.

Second this...on occasion all threads morph into the same topic!

Without the mods doing such a great job it would dissolve into chaos.

Anyway back to topic I also like what laa yosh has to say about game engines probably using some mega texturing scenaio..which would help durango.

Im guessing microsoft built the system to be better optimised for the top studio tech engines...im pretty sure microsoft has not spent 8 sodding years twiddling their thumbs then mashing a cheap wii u like console together...this thing has been tooth combed.

Edit...also it does then raise the other scenario which I think laa yosh also brought up, outside of its intended mega texture engine targets. ..durango would surely be out gunned?.
 
I think virtual textures will be implemented more often than not this gen. There are hardware features built into AMD GCN to support it. I think virtual texturing (not necessarily unique texturing for every surface) is just the smart way to go. AMD has OpenGL extensions to support it "easily", so I imagine Microsoft will provide a Direct3D version of that same functionality. The memory managers in GCN should handle all of the page tables for the tiles. Any time a tile is requested from the texture(tile?) cache, and the cache misses, I'm guessing the appropriate DME would be triggered to copy that tile into the cache (compressed, uncompressed as need). I'm a layman, so from my birds-eye understanding, that is what would make sense. It relieves the GPU from moving tiles into the cache and doing the (de)compression work that needs to be done.

My understanding (from sebbbi's post about virtual texturing, http://forum.beyond3d.com/showpost.php?p=1580827&postcount=39) is that tile caches for 720p would not fit in ESRAM unless they were compressed, or split in two for screen tiling. GCN supports an uncompressed tile size of 128x128 32bit, matching sebbbi, Lionhead and id. At Sebbbi's suggested tile cache size, it would be a 64 MB tile cache. Lionhead uses a smaller tile cache in their solution. Not sure how they differ on that. Smart people may have more fun speculating on this idea than I would.

Maybe I'm thinking about this wrong and the tile cache would sit in DDR3 and the visible tiles would be moved to ESRAM.
 
Orbis comparison crap extricated. Technical comparisons to help understand the subject are welcome, but business discussion has no presence here.

Durango Thread - what is Durango hardware (every post working towards answering that question)
Orbis Thread - what is Orbis hardware (every post working towards answering that question)
Vs Thread - dumping ground for incessant off-topic content in the above two intelligent consideration threads.
 
Any time a tile is requested from the texture(tile?) cache, and the cache misses, I'm guessing the appropriate DME would be triggered to copy that tile into the cache (compressed, uncompressed as need).

Just one correction -- this is not done synchronously, and you don't necessarily want to do this for every miss. The correct reaction to missing the tile is to draw from a smaller mip level (which can all be kept in memory because they are tiny compared to the full textures), and mark that you missed a texture. Then, between frames, you look what textures you missed the most and bring those up.
 
So design pilosophy of Durango seems to be. It is better to have 70 units of power (and wattage) at 98% of average utilization, than 100 units at 65%.
At first sight looks like developers will take a short time to use most of the console. But I hope they will find clever uses for ESRAM, DME and the "unknown".
 
So design pilosophy of Durango seems to be. It is better to have 70 units of power (and wattage) at 98% of average utilization, than 100 units at 65%.
At first sight looks like developers will take a short time to use most of the console. But I hope they will find clever uses for ESRAM, DME and the "unknown".

Yes, so somewhere on someone's desk I expect there was a complex equation.

Code:
Custom hardware = a*(die space, and hence, yield per wafer times cost of wafer, saved using DMEs and eSRAM + other stuff vs. more CUs for x amount of peak achievable performance) + b*(time saved optimizing performance for 1st party games and more games produced) + c*(additional revenue from extra games with shortened dev time or games that would have otherwise been exclusive from 3rd parties) + d*(cost saved on board, enclosure and thermal solution for less hot die) - e*(NRE above a vanilla design with CPUs + more CUs)
 
So design pilosophy of Durango seems to be. It is better to have 70 units of power (and wattage) at 98% of average utilization, than 100 units at 65%.
At first sight looks like developers will take a short time to use most of the console. But I hope they will find clever uses for ESRAM, DME and the "unknown".

We have no reason to currently think core efficiency will be that high. All we know is bandwidth as it exists in that design is fairly low. And the added some work arounds to try to tackle this problem. Whether or not it is an actually efficient desgin we probably won't know for at least a year or two after launch once devs come to grips with it. I predict lauch games will struggle though. Similar to what the ps3 went through
 
We have no reason to currently think core efficiency will be that high. All we know is bandwidth as it exists in that design is fairly low. And the added some work arounds to try to tackle this problem. Whether or not it is an actually efficient desgin we probably won't know for at least a year or two after launch once devs come to grips with it. I predict lauch games will struggle though. Similar to what the ps3 went through

He was exaggerating to make a point.

But I disagree. The design decisions they've made are to help developers where they usually run into traps. Bandwidth starved? Use the eSRAM. Afraid about coherency? Virtual addressing. Problem getting large textures? Use the built-in compression (or the tiling acceleration!). It genuinely seems they tried to look at the trappings of modern GPU usage and mitigate those rather than throw more CUs and more bandwidth at it.

The ps3's problem was different. It was an in-order extremely wide CPU. Devs were coming from single thread CPUs. On top of that, it's impossible to hit its peak theoretical numbers. And their memory pool was separate and shaders were not unified. The latter really wasn't a problem at the time as they could tailor their shader loads, but compare that to the 360 and then try to go to the PS3.

The architectures are extremely similar between Durango and Orbis, and from a technical perspective, it seems the only issues they'd have is not enough units (but that would be a struggle the console's entire life), or the DMEs and eSRAM isn't making up the bandwidth difference between the two.

I think launch games will be just fine.
 
We didn't really get any exact comparisons - the 'roughly equal' stuff can be deduced from the final locked specifications alone, without any hardware.

Also, final real-world performance will heavily depend on the type of engine used. If virtual texturing is a part of an engine, Durango will probably be able to get closer to Orbis, for example - at least based on what we currently know/believe. Oh and it will also require a proper port too.

Surely ms has been in detailed discussions with all major third parties on the rendering hardware in Durango, ensuring their engines are ready to leverage what's under the hood? Heck, I'm sure a lot of this design was born out of what devs said their engines *will* look like in 3 years. (From ~2009)
 
finally someone who really knows the truth

And we know he knows the truth how ? , he hadn't said anything with substance and ill he does be is just a big a troll as superdae I wouldn't be surprised if it was him trying to get people to believe him.

On topic I want to see the hardware planes more then anything seems to be the last bit of technically interesting hardware imo
 
The ps3's problem was different. It was an in-order extremely wide CPU. Devs were coming from single thread CPUs. On top of that, it's impossible to hit its peak theoretical numbers. And their memory pool was separate and shaders were not unified. The latter really wasn't a problem at the time as they could tailor their shader loads, but compare that to the 360 and then try to go to the PS3.

It is easy to say that now about the PS3 with hindsight. But 7 years ago, the proponent s of the PS3s design were saying a lot of the same things about how much more efficient it could be per core because of many dma fetches in flight etc, 2 pools of ram etc. And it's not that they were completely wrong. But the theoretical potential proved difficult even with a lot of additional work. And sure there were other shortcomings to blame. But it is only easy to point at those now because of hindsight. But in the end, the general sentament from devs was give us something more straight forward. And this was MSs position as well until now it seems.s

Also we don't even know about the cost effectivness of these designs yet. This is only a win for MS if this comes out significantly cheaper
 
Status
Not open for further replies.
Back
Top