Xbox One (Durango) Technical hardware investigation

Status
Not open for further replies.
I thought it had been confirmed esram?

There's been some confusion going around. eSRAM is essentially eDRAM. Both have 1 transistor and 1 capacitor per cell. I'm sure someone else can explain more details.

edit: This is decent.

Thanks...but lets be honest that doesnt make it any more flattering :/..

The cpu would have looked decent in 2008...why so low clocks??

Because if it's on an APU, that's more budget for the GPU. Jaguar is still well suited to this task. Low power, OoO with AVX and other advanced FP capabilities. The only thing I'd rather have is a mobile quad core Haswell, which isn't possible as an APU solution with an AMD or Nvidia GPU.
 
Last edited by a moderator:
There's been some confusion going around. eSRAM is essentially eDRAM. Both have 1 transistor and 1 capacitor per cell. I'm sure someone else can explain more details.



Because if it's on an APU, that's more budget for the GPU. Jaguar is still well suited to this task. Low power, OoO with AVX and other advanced FP capabilities. The only thing I'd rather have is a mobile quad core Haswell, which isn't possible as an APU solution with an AMD or Nvidia GPU.

Mmm ok...but the gpu isnt massive. .and that doesn't explain the puny clocks...
 
There's been some confusion going around. eSRAM is essentially eDRAM. Both have 1 transistor and 1 capacitor per cell. I'm sure someone else can explain more details.



Because if it's on an APU, that's more budget for the GPU. Jaguar is still well suited to this task. Low power, OoO with AVX and other advanced FP capabilities. The only thing I'd rather have is a mobile quad core Haswell, which isn't possible as an APU solution with an AMD or Nvidia GPU.

There's different forms of eSRAM, what you're describing is 1T-SRAM which is really eDRAM. True SRAM has 6 transistors per bit (or more). We're all just guessing at what is actually in durango.
 
Mmm ok...but the gpu isnt massive. .and that doesn't explain the puny clocks...

No, it's not. With the extra custom circuitry plus the GPU, they probably hit a less aggressive overall TDP compared to generations past.

The puny clocks are because that's what Jaguar was designed to. It won't work at significantly higher clocks because the logic wasn't designed to close timing at those numbers. They would have had to design a whole new CPU.

There's different forms of eSRAM, what you're describing is 1T-SRAM which is really eDRAM. True SRAM has 6 transistors per bit.

Which AFAIK is never referred to as eSRAM, because it only comes embedded. And we'd never see SRAM this size on this process.
 
No, it's not. With the extra custom circuitry plus the GPU, they probably hit a less aggressive overall TDP compared to generations past.

The puny clocks are because that's what Jaguar was designed to. It won't work at significantly higher clocks because the logic wasn't designed to close timing at those numbers. They would have had to design a whole new CPU.



Which AFAIK is never referred to as eSRAM, because it only comes embedded. And we'd never see SRAM this size on this process.

1T-SRAM isn't usually referred to as eSRAM either, which is why we're still guessing.
 
I'm still thinking it's plain SRAM. But the 100GB/s is puzzling, is it possible the eSRAM is on a daughter die like the 360? That would open up some additional possibilities for pseudo SRAM, because many of them require a special process.
 
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 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, gamers may still not see the benefits of these display planes until they see the final OS. Even if display planes were used as part of the display engine in car kits, older consoles and PCs, people are generally unaware of them. In games, the multiplatform developers will not let the presence/absence of display planes compromise parity. They have other (software-based) optimization techniques.

In traditional console games, we don't typically have other apps running in parallel until in-game blade UI and XMB shows up. When MS starts to flaunt these free composition and alternate display in their apps and OS UI, like iOS transitions, the display planes should standout more.
 
Thanks...but lets be honest that doesnt make it any more flattering :/..

The cpu would have looked decent in 2008...why so low clocks??

High clock speeds are generally only attainable by having very long pipelines with very short stages. Essentially you can get your clock rate up by doing less work per cycle.

A more sophisticated cpu with a lower clock but a more efficent pipline can achive much greater real world throughput just by doing more work per cycle
 
I'm still thinking it's plain SRAM. But the 100GB/s is puzzling, is it possible the eSRAM is on a daughter die like the 360? That would open up some additional possibilities for pseudo SRAM, because many of them require a special process.

If they only needed 100GB/s, regular SRAM would be extreme overkill. A daughter die would also go against the idea of a monolithic APU. I think their goal is one die, simple process, no more complexity than is needed.
 
If they only needed 100GB/s, regular SRAM would be extreme overkill. A daughter die would also go against the idea of a monolithic APU. I think their goal is one die, simple process, no more complexity than is needed.
But any memory other than standard SRAM does add complexity, and most require special process steps, are not necessarily available on 28nm yet, and cause trouble with later shrinks. Maybe SRAM gives them much better latency, and that could be more useful for GPU compute tasks than bandwidth.
 
But any memory other than standard SRAM does add complexity, and most require special process steps, are not necessarily available on 28nm yet, and cause trouble with later shrinks. Maybe SRAM gives them much better latency, and that could be more useful for GPU compute tasks than bandwidth.

SRAM is unlikely simply because it would be gigantic.
 
High clock speeds are generally only attainable by having very long pipelines with very short stages. Essentially you can get your clock rate up by doing less work per cycle.

A more sophisticated cpu with a lower clock but a more efficent pipline can achive much greater real world throughput just by doing more work per cycle

Cheers..well that explains that then...
 
There's been some confusion going around. eSRAM is essentially eDRAM. Both have 1 transistor and 1 capacitor per cell. I'm sure someone else can explain more details.

edit: This is decent.



Because if it's on an APU, that's more budget for the GPU. Jaguar is still well suited to this task. Low power, OoO with AVX and other advanced FP capabilities. The only thing I'd rather have is a mobile quad core Haswell, which isn't possible as an APU solution with an AMD or Nvidia GPU.

Cheers just had a read...1TSram is 1 transistor dense stuff. .where as the real sram is called 6Tsram and is much larger.
 
My gut feel, which can of course be wrong, is: It's for enabling new (and consistent) user experience.

The OS plane will be used for that. The other two probably won't.

Resource saving is secondary because in the first patent quotes you highlighted, we see the word "sacrificed". Dynamic resolution is activated when certain visual elements such as resolution has been compromised to hit higher framerate. This is different from optimization techniques that improve or do not impact visuals (e.g., culling).

This comment seems misleading since we know why devs utilize things like dynamic and/or adjusted res. It's usually in a game that needs every ounce of graphics power squeezed out of it in the first place. The display planes are there to help give devs more control over resource management. And if you read the background/summary of the patent it is pretty clear their goal is absolutely to offer QoS guarantees based on saving resources. I would also disagree with your suggestion that dynamic res/fps/etc isn't to be considered a component of optimization.

Your steering wheel HUD example is ok. You don't have to follow the patent example to the tee.

I know that, but my initial post on that was misleading as it was drawing an inference from that specific image which upon further reading was clearly incorrectly based on my misunderstanding of it. The wheel was part of the game plane.

I am more curious to see how far devs can stretch the HUD plane in terms of rendering non-HUD stuff to it. Lots of modern HUDs these days are no longer just straight up 2D overlays, so presumably there is leeway there. If there is a way to have some meaningful elements of the game world being displayed in that HUD plane (arm/gun in an fps or car interior in a racing game, etc) that could be a pretty huge deal imho. I'd imagine others here could outline some of the limitations (or their guesses of the limitations) based on how the planes are being blended?

If there is no real technical distinction being made in the 2 application/game planes other than forcing one to be on top of the other, than maybe devs could leverage it as a foreground/background sort of thing? If so, that could seemingly add a LOT to the resource saving side of things I'd imagine since depending on the cutoff having lower res backgrounds isn't really a problem. Hell, devs use system resources as it is just to blur out backgrounds anyhow! :smile:

Most of the other points you listed from the patents can be done using software on Durango or Orbis too.

But it costs resources to do it via software...moreso than it would on Durango's setup, no?

I am more interested in the workflow, such as the virtual texture workflow, in Durango. If they do enough work during bake time, they may be able to load more details and pre-calculated data into the 8GB RAM.

I am also interested in seeing this. I know very little about virtual memory but it sounds like it could be the sort of things that might save Durgano's setup a lot of processing and bandwidth to get the same output. If that is true it would make a lot of Durango's design decisions actually make sense.
 
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.

It may be possible that their design decisions are based on delivering a box built to leverage virtual memory/textures/geometry and heavy tiling. Based on what I've read such an approach would be able to net you the same visual output with significantly less powerful specs. I think they probably wanted to spread out the processing and bump up efficiency across the board specifically for this reason. Taking high end software concepts and implementing solutions for them via hardware sounds like something devs would be thrilled with.
 
The OS plane will be used for that. The other two probably won't.

The DME is an inherent part of the system. It will be used for "everything".

This comment seems misleading since we know why devs utilize things like dynamic and/or adjusted res. It's usually in a game that needs every ounce of graphics power squeezed out of it in the first place. The display planes are there to help give devs more control over resource management. And if you read the background/summary of the patent it is pretty clear their goal is absolutely to offer QoS guarantees based on saving resources. I would also disagree with your suggestion that dynamic res/fps/etc isn't to be considered a component of optimization.

Where dynamic resolution is concerned, the QoS is guaranteed by sacrificing something, as the patent put it. I didn't say it's not a component of optimization. I pointed out there are other software optimization techniques developers may use to avoid sacrifices in a standalone game. The developers will/should focus on those techniques first.

The display planes are helpful in compositing (for free). But within a game, I doubt the saving is great. They can control the update rate, timing, quality, quantity, and region of different elements by software.

It seems that the display planes are more useful and their benefits more apparent when you have layers of information from different sources. e.g., Custom software HUD over a dedicated video decoder output, OS mouse cursor over an app window, miniaturized game output in OS screen, AR over Kinect video or Blu-ray. It may mean Durango can compose all the different output together while ensuring the responsiveness of the OS. These are part of the "new" experiences I expect in the Durango OS.

But it costs resources to do it via software...moreso than it would on Durango's setup, no?

Yes, but how resource intensive is the final compositing for a game ? The GPU is very efficient at pixel operations, especially when all the in-game visual elements are generated by it. The programmer has full control over what not to draw, and how frequently to draw the visible ones.

As others have pointed out, without the display planes, it is not uncommon to have color conversion, scaling, compositing done as part of the display engine too (Many have simple hardware overlays to do this). The Durango display planes seem more elaborate in that you can divide them into 4 quadrants to mask obscured output. As such, they may be there because Durango's OS relies on them for a new and consistent experience.
 
Just from reading and my quite modest understanding, the Durango is starting to remind me of the Sega Saturn and it's small army of processors. If the PS4 is released first and, with it's more straightforward, potentially more capable design, becomes the lead platform, I can see all these little "custom" pieces becoming a lot of extra effort to maintain parity across the 2 machines. I wonder how much the devs will push to achieve it. Look at the difference in effort this gen maximizing the capability of Cell's nuances between 1st and 3rd party devs.

PS2 also had a small army of processors and did quite well compared to relatively more straightforward Dreamcast. That one turned out differently. :)

Regards,
SB
 
Nothing about this setup prevents you from doing culling, or any optimizations. It may or may not make dynamic resolution easier, but by no means makes it automatic either. This hardware is there for QoS guarantees, and to provide some simple workarounds for visual issues, like HUD and overlay resolutions in non-native resolution games.

That last little bit also made me think that it could give a graphical advantage in some respects if some game, for example, only ran at 720p or any other sub 1080p resolution, but Durango's Game UI was at 1080p while Orbis's Game UI was at the same resolution as the game.

For some side by side comparison like Digital Foundry, you'd be able to pick it apart. For your average consumer though they may think the game with the sharp native res UI is actually better looking than the other one, even if the other one had, say, better shadows and lighting.

Of course, if that were the case, that would force Orbis developers to also have a native res UI. But if there's no hardware support it may require more GPU resources, thus leveling the playing field regardless.

Regards,
SB
 
Status
Not open for further replies.
Back
Top