Xbox One (Durango) Technical hardware investigation

Status
Not open for further replies.
Strange that microsoft didn't disclosed something about the SHAPE processor in the box.
Or is it something the other consoles also have?
Inbe4 its in the cloud
 
Regarding the CPU:




http://www.engadget.com/2013/05/21/xbox-one-architecture-panel-liveblog/

A normal Jaguar can do 4 ops per core per cycle?

A Jaguar core can issue 6 ops per cycle -- two memory, two int alu, and two fpu/simd ops. However, it can only decode two, and retire two, so the average rate cannot ever go above two.

The primary reason for the 6-wide issue is that between decode and retire the separate pipelines are effectively independent and there's no reason they shouldn't be able to issue in parallel. However, being able to issue more than you can sustain in the long term does have some advantages, notably, a bad data stall will cause your execution to stall until the data arrives, while the decode parts can happily run forward until all the queues and buffers are full. When the data arrives, being able to issue more ops means you can clear these queues, and the retire can again catch up the next time you stall.

So basically, having more issue resources means that you can get closer to the max of 2 in practice.

Of course, picking the number 6 in particular is just the kind of "xbox 360 gpu has x TFlops" we all know and love from the past gen. There are many numbers that made varying amount of sense, this one got picked because it's the biggest one.
 
http://www.anandtech.com/show/6972/xbox-one-hardware-compared-to-playstation-4/2

anand has a look at xbone hardware analysis, and it's written by anand who i typically find insightful. still looking, but already found this


There’s no word on clock speed, but Jaguar at 28nm is good for up to 2GHz depending on thermal headroom. Current rumors point to both the PS4 and Xbox One running their Jaguar cores at 1.6GHz, which sounds about right. In terms of TDP, on the CPU side you’re likely looking at 30W with all cores fully loaded.s


To make up for the gap, Microsoft added embedded SRAM on die (not eDRAM, less area efficient but lower latency and doesn't need refreshing). All information points to 32MB of 6T-SRAM, or roughly 1.6 billion transistors for this memory. It’s not immediately clear whether or not this is a true cache or software managed memory. I’d hope for the former but it’s quite possible that it isn’t. At 32MB the ESRAM is more than enough for frame buffer storage, indicating that Microsoft expects developers to use it to offload requests from the system memory bus. Game console makers (Microsoft included) have often used large high speed memories to get around memory bandwidth limitations, so this is no different. Although 32MB doesn’t sound like much, if it is indeed used as a cache (with the frame buffer kept in main memory) it’s actually enough to have a substantial hit rate in current workloads (although there’s not much room for growth).

Vgleaks has a wealth of info, likely supplied from game developers with direct access to Xbox One specs, that looks to be very accurate at this point. According to their data, there’s roughly 50GB/s of bandwidth in each direction to the SoC’s embedded SRAM (102GB/s total bandwidth). The combination of the two plus the CPU-GPU connection at 30GB/s is how Microsoft arrives at its 200GB/s bandwidth figure, although in reality that’s not how any of this works. If it’s used as a cache, the embedded SRAM should significantly cut down on GPU memory bandwidth requests which will give the GPU much more bandwidth than the 256-bit DDR3-2133 memory interface would otherwise imply. Depending on how the eSRAM is managed, it’s very possible that the Xbox One could have comparable effective memory bandwidth to the PlayStation 4. If the eSRAM isn’t managed as a cache however, this all gets much more complicated.

There are merits to both approaches. Sony has the most present-day-GPU-centric approach to its memory subsystem: give the GPU a wide and fast GDDR5 interface and call it a day. It’s well understood and simple to manage. The downsides? High speed GDDR5 isn’t the most power efficient, and Sony is now married to a more costly memory technology for the life of the PlayStation 4.

Microsoft’s approach leaves some questions about implementation, and is potentially more complex to deal with depending on that implementation. Microsoft specifically called out its 8GB of memory as being “power friendly”, a nod to the lower power operation of DDR3-2133 compared to 5.5GHz GDDR5 used in the PS4. There are also cost benefits. DDR3 is presently cheaper than GDDR5 and that gap should remain over time (although 2133MHz DDR3 is by no means the cheapest available). The 32MB of embedded SRAM is costly, but SRAM scales well with smaller processes. Microsoft probably figures it can significantly cut down the die area of the eSRAM at 20nm and by 14/16nm it shouldn’t be a problem at all.

Even if Microsoft can’t deliver the same effective memory bandwidth as Sony, it also has fewer GPU execution resources - it’s entirely possible that the Xbox One’s memory bandwidth demands will be inherently lower to begin with.

The Kinect sensor itself is one of 5 semi-custom silicon elements in the Xbox One - the other four are: SoC, PCH, Kinect IO chip and Blu-ray DSP (read: the end of optical drive based exploits).

Although necessarily superficial, looks like another excellently well done article by Anand.
 
Hmm.. will we see much GPGPU outside Sony 1st party. There just isnt much room if you want to wow with gfx

There was talk on the XB One architecture panel about how the GPU had multiple threads for graphics and compute jobs alike. They specifically mentioned collision detection as an obvious GPGPU job.

On the software side, MS is further ahead than Sony with their C++ AMP framework, where you can build apps that involve both the CPU and the GPU.

Cheer
 
On the software side, MS is further ahead than Sony with their C++ AMP framework, where you can build apps that involve both the CPU and the GPU.

I would like to reply to this, no "X does better then Y" but I would go OT :(

BTW DF just made an article here.
 
Also, what is the small round connector next to the ethernet socket on the rear I/O panel of the device? Looks like a 3.5mm audio jack, but I don't really see what reason such a connector has to exist on the XB1, or at least not on the rear of the console like that where it's very hard to reach and awkward to plug into...

Could be IR connector...
 
Strange that microsoft didn't disclosed something about the SHAPE processor in the box.
Or is it something the other consoles also have?
Inbe4 its in the cloud

Sound is not a system seller and both consoles will sound great.

Maybe bkilian can clarify (maybe not lol) but shape is more about kinect than actual sound we hear. Shape includes all the kinect stuff first leaked by vgleaks as seperate items I think
 
Sound is not a system seller and both consoles will sound great.

Maybe bkilian can clarify (maybe not lol) but shape is more about kinect than actual sound we hear. Shape includes all the kinect stuff first leaked by vgleaks as seperate items I think

As far as what I read, you are wrong. A small piece of SHAPE was supposed to be echo/noise cancellation for Kinect. The rest of it is all about game audio.
 
Hmmm...this quote from Anandtech seems interesting:


"Although 32MB doesn't sound like much, if it is indeed used as a cache (with the frame buffer kept in main memory) it’s actually enough to have a substantial hit rate in current workloads (although there’s not much room for growth)........If it’s used as a cache, the embedded SRAM should significantly cut down on GPU memory bandwidth requests which will give the GPU much more bandwidth than the 256-bit DDR3-2133 memory interface would otherwise imply. Depending on how the eSRAM is managed, it’s very possible that the Xbox One could have comparable effective memory bandwidth to the PlayStation 4. If the eSRAM isn't managed as a cache however, this all gets much more complicated."

From the way I understand it, the eSRAM in the XO isn't software managed but a true cache. That is, it is transparent to the developer unlike the eDRAM in the 360. Anand seems to be hitting the point ERP and Gubbi were making about the flexibility of the eSRAM and its potential benefits. My question is; how does this cut down on the GPU memory bandwidth request?
 
Hmmm...this quote from Anandtech seems interesting:


"Although 32MB doesn't sound like much, if it is indeed used as a cache (with the frame buffer kept in main memory) it’s actually enough to have a substantial hit rate in current workloads (although there’s not much room for growth)........If it’s used as a cache, the embedded SRAM should significantly cut down on GPU memory bandwidth requests which will give the GPU much more bandwidth than the 256-bit DDR3-2133 memory interface would otherwise imply. Depending on how the eSRAM is managed, it’s very possible that the Xbox One could have comparable effective memory bandwidth to the PlayStation 4. If the eSRAM isn't managed as a cache however, this all gets much more complicated."

From the way I understand it, the eSRAM in the XO isn't software managed but a true cache. That is, it is transparent to the developer unlike the eDRAM in the 360. Anand seems to be hitting the point ERP and Gubbi were making about the flexibility of the eSRAM and its potential benefits. My question is; how does this cut down on the GPU memory bandwidth request?

I still have some things I need to learn about the move engines but doesn't it seem logical that the ESRAM would function as a cache since they already have the move engines managing data? This at least makes sense to me as they could quickly end up over engineering the solution otherwise.
 
bkilian,

Any idea if the video output will follow video standards or are we looking at funky gamma curves and other such oddities agian? If I use it as my BluRay player, I don't want to the signal altered.
 
Any tip about what do MS refers to when talking about Kinect natural language processing?.Seing the conference it still seems similar to spoken commands ala old version of google search and not Siri alike in which you can say "i would like to see a film" instead of explicit command "Xbox watch film".I supposee Bkillian could know about whether there is truly natural language processing as well as speech recognition processing.
By the way the speech recognition of the conference was astounding, the improvements MS has done in this with deep learning make it similar to google's now assistant and way better than Siri's nuance.
 
Last edited by a moderator:
I still have some things I need to learn about the move engines but doesn't it seem logical that the ESRAM would function as a cache since they already have the move engines managing data? This at least makes sense to me as they could quickly end up over engineering the solution otherwise.

Like I said, the eSRAM can be used as cache; the vgleaks article and the Durango paper points to this. It can also be used as a framebuffer if a dev wants to. The DMEs seems to be there to assist both use.
 
Status
Not open for further replies.
Back
Top