Xbox One (Durango) Technical hardware investigation

Status
Not open for further replies.
Display Planes... another "custom" hw block that is not really... custom.
This stuff is also known as hardware overlays. It has become so common that linux has standard API in the drm subsytem to handle it (named drm planes, funny enough).

Quick look through drm (linux kernel gpu/video) drivers reveals:


  • AMD/Nvidia - they have much more complicated drivers than anything else and my quick look through them did not reveal anything useful apart from hardware cursor support. So they may or may not support drm planes (I don't have hw to check sadly). Or they may support it in hw but not expose it in nouveau/radeon (I would not be surprised).

If you go to the embedded world (arm SoCs mostly, those that have linux drivers) you'll see that it's basically everywhere:



  • OMAP (display driver for TI SoCs) also has planes support (as I've used them on one of the boards) though I don't remember the count. Their driver is rather custom one (to put it mildly) so I cba looking at it to be more precise.


  • There is also crazy stuff like this: 12:59 < pinchartl> and some more food for thought, I have another hardware features that I need to support: chained CRTCs. the first CRTC can compose up to 4 planes, with scaling, and its output is fed to a second CRTC that can composite it with up to 7 other planes, without scaling (crtc is a linux drm thing which loosely corresponds to display/scanout engines)

What I'm trying to say here is that this 'Display Planes' hw may very well be custom. In a sense of exactly this hw block not appearing anywhere else (I'd be surprised though). But there is surely nothing special about it, nor custom regarding what it does. It's a part of a lot of display engines in modern SoCs (I'd say of all of them that go into phones/tablets).
And there is a reason for that actually: offloading compositing. Their most common usecase is compositing video (with colourspace conversion, gamma correction, scaling etc) done by the display engine without doing it all in memory. There is other stuff they are used for obv (afaik there was a talk of Android using them for notification bar for example).

I actually would not be surprised if Orbis also has it in some form. Mostly because it's so common now, it's easy to add and it gives easily exploitable benefits.

PS. And this patent is... the same old "doing stuff with a hat on". Meh.
 
What I'm trying to say here is that this 'Display Planes' hw may very well be custom. In a sense of exactly this hw block not appearing anywhere else (I'd be surprised though). But there is surely nothing special about it, nor custom regarding what it does.
Was anyone saying otherwise? I don't think there's any point scoring for originality in console engineering, so I don't think anyone here really cares is something is brand-new or a recycled concept (and almost every modern idea is old when you trace its roots).

The only point of discussion is Durango has hardware support for this with given details, which means one less thing the GPU will have to do. As the function is not common to all AMD GPUs, it's possible that this feature is not shared with Orbis, giving us something to compare. And even if it is, this is the Durango thread, and not the versus thread, so 'anything you can do, I can do better' is pretty immaterial to this discussion.
 
this is the Durango thread, and not the versus thread, so 'anything you can do, I can do better' is pretty immaterial to this discussion.
If my post sounded this way, I'm sorry. Was not intending to (and frankly, rereading it I don't see it being 'versus' or whatever you might have felt). I'm sorry for mentioning Orbis though.
I simply wanted to show people that it's a common thing in modern (and not so) hw with fairly well known capabilities.

I also decided to post after comments like
patsu said:
If my guess is correctly, then people probably can't see the real benefits of these display planes until they see the Durango OS running for real. I think resource saving is secondary (and there are substitutes using software), these display planes should be able to enable new and consistent user experience in the final OS. ^_^
because people actually see the benefits of this hw on phones/cars/tvs and even some pcs all the time

It was also a reaction to this "patent"... 'thing'.
 
Well, we still have the ESRAM latency and the CPU analysis to search for the special sauce. Hold on!.

Maybe this special sauce is just the combined efficiency of all of it put together?

Im interested in the cpus...I just think an 8 core jaguar (if thats what it is?) @1.6ghz with 128bit simd is going to be too weak....heres hoping its a custom design with some 256bit avx functions or better and some cache/pipeline changes...maybe some not needed stuff chopped out for efficiency (someone mentioned this some pages ago..x87 instructions? Fp64?)
 
Another thing..why a whopping 3gb ram and 25% cpu resources??..

There is something more at play here...maybe one core for system..and one core for kinect/dma?..
What about the ram??
 
maybe one core for system..and one core for kinect/dma?..

I think there's only one core reserved for the system. The other disabled one is for yields. Variability and functional yields are worse now than they have ever been. You really don't want to toss a soc with a gpu, 8 cores, and loads of cache just because one of the cores has a fault.

Basically everything in the chip that takes more than a few mm^2 of space needs some redundancy for yields. Similarly, I'd bet good money that if devs have access to 12 CUs there are at least one more, probably 2, present but disabled for yields.

PC GPUs can only be sold as full chips because there are separate SKUs for disabled ones. If there weren't, the full chips would be more than twice as expensive. Consoles are unlikely to have those separate skus.
 
With each new leak is increasingly clear that there is no "secret sauce" and the next xbox is simply underpowered.The only doubt/hope I have left is that bkilian had spoken(if I remember correctly) of blocks proposed to help the graphics and increase performance but perhaps did not want to be too critical of his former colleagues.
 
I think there's only one core reserved for the system. The other disabled one is for yields. Variability and functional yields are worse now than they have ever been. You really don't want to toss a soc with a gpu, 8 cores, and loads of cache just because one of the cores has a fault.

Basically everything in the chip that takes more than a few mm^2 of space needs some redundancy for yields. Similarly, I'd bet good money that if devs have access to 12 CUs there are at least one more, probably 2, present but disabled for yields.

PC GPUs can only be sold as full chips because there are separate SKUs for disabled ones. If there weren't, the full chips would be more than twice as expensive. Consoles are unlikely to have those separate skus.

Thanks makes sense..cell had just such a scenario did it not?

Well this makes performance projections even worse...essentially then cpu wise we have a comparable situation to xbox 360. ..6 low clocked out of order threads vs 6 high clocked inefficient in order threads....doesnt seem much of an upgrade now does it?

Only cache has quadrupled and bandwidth has more than doubled. .the system core would save some cpu cycles...but over all im dissapointed to be honest...was expecting somewhere in the region on 2.5ghz....
 
Well this makes performance projections even worse...essentially then cpu wise we have a comparable situation to xbox 360. ..6 low clocked out of order threads vs 6 high clocked inefficient in order threads....doesnt seem much of an upgrade now does it?

You can view the 360 CPU as 3 x 3.2GHz cores with multi threading, or as 6 1.6GHz cores, but not both.

Cheers
 
With each new leak is increasingly clear that there is no "secret sauce" and the next xbox is simply underpowered.The only doubt/hope I have left is that bkilian had spoken(if I remember correctly) of blocks proposed to help the graphics and increase performance but perhaps did not want to be too critical of his former colleagues.

Well he mentioned 3 blocks:
-1 assisting graphics ( move engines, and asuming they are really different from simple DMA engines ).
-1 that could assist graphics ( ESRAM )
-1 the sound DSP.

i dont count the display planes because even PS2 had those and i see it as a 360 scaler evolved. The main doubt now is: is the ESRAM really SRAM with 20 or less cycles latency?. That is the thing that could approach us the 12 CUs to the 14 rendering CUs of Orbis.
And the another doubt is if the CPU is more SIMD capable to approach us to the 4 special CUs in Orbis.
 
Well he mentioned 3 blocks:
-1 assisting graphics ( move engines, and asuming they are really different from simple DMA engines ).
-1 that could assist graphics ( ESRAM )
-1 the sound DSP.

If these are the blocks that bkilian referred maybe they will improve some performance but nothing miraculous.
Unfortunately,the GPU choice by MS for the xbox next is weak.
 
If these are the blocks that bkilian referred maybe they will improve some performance but nothing miraculous.
Unfortunately,the GPU choice by MS for the xbox next is weak.

Compared to what? Its plainly obvious that Sony has more horses...and compared to mm2 silicon of ps360....but to its competitors of today it is sitting quite nicely imo.

Plainly there is going to be more to durango/720 than just gpu horse power.
 
Status
Not open for further replies.
Back
Top