Xbox One (Durango) Technical hardware investigation

Status
Not open for further replies.
Worse you might be acting as the multiplayer server, and you don't want to DC everyone else just because you answered a call.
 
That would be entirely up to the design targets of the implementation. Bandwidth is more a function of clocks and the total width of the read and write paths. Unless you really care about sub-ns latencies--and at these capacities and distances on the die you don't, there is no conclusion to draw based on the type of memory cells employed. To think differently is to forget about IBM's POWER7 L3 cache.


What measures differ by 10x?
I am having trouble keeping up with this thread. It is growing fast.

In regards to your question.... By orders of magnitude I meant the scale of certain amount -which was not determined by powers of ten- but by the multiplication of a percentage, more concretely 10%.

In that case the EDRAM of the X360 is an order of magnitude faster -bandwidth wise, I am not talking about latency- than the eSRAM on XBO.

More concretely 150% faster, if my maths aren't wrong, that's why I mentioned an order of magnitude.

These differences and the emergent realities of eSRAM vs EDRAM have forced rearchitecting the entire console.
 
I'm failing to understand the purpose of the constrained state if you cannot interact with the game? What is the point of leaving it running? Why not just suspend it instead? Kind of kills the idea of multitasking as well, if this is the state your game is put into when you run Skype at the same time, for example. I'd have to see an explanation of the usefulness of this.

I think the difference might be speed of return (back to a fully running state). With the use case being a full screen Skype call or TV screen vs a snapped Skype call or TV screen. In a suspended state it has no access to the GPU, so, I would assume its framebuffer to its display plane would be dropped as well, wouldn't it?

The terminated state is nice. Basically a VM snapshot, I guess. You just resume, like you were playing a movie where you left off. No menus to jump through.

A snapshot (as I'm use to them at least) would typically cover quite a bit more. It can include a dump of the memory (does by default) but the biggest functional purpose is the creation of new differential files for a VM's virtual disks (along with its config at the time of the snapshot), and the VM then runs from the differential. It allows you to revert the VM back to a previous state or consolidate the differential changes back to the original. The terminated state sounds like its essentially just dumping the physical memory to the disk somewhere.

EDIT

Worse you might be acting as the multiplayer server, and you don't want to DC everyone else just because you answered a call.

I didn't think of that. That might be a bad thing. :p I wonder how an MP game would gracefully handle the loss of 2 cores in such a scenario? They don't really pause when bringing up a system menu like SP games do, so, everything is still active.
 
A prompt when you're about to suspend a game is probably sufficient. So, for constrained state, that would be game snapped with app in the primary running state, for a lack of a better descriptor? I guess that makes some sense, especially if you're matchmaking or whatever in the background. In the case where the game is in front and the app is in the snapped side view, then the game is in the running state, I guess. At least I hope so.
 
1) Running: The game is loaded in memory and is fully running. The game has full access to the reserved system resources, which are six CPU cores, 90 percent of GPU processing power, and 5 GB of memory. The game is rendering full-screen and the user can interact with it.

10% GPU reservation? First we've heard of this I think.

I like terminated state too. Waiting to boot into games dissuades me from playing them sometimes.
 
I am having trouble keeping up with this thread. It is growing fast.

In regards to your question.... By orders of magnitude I meant the scale of certain amount -which was not determined by powers of ten- but by the multiplication of a percentage, more concretely 10%.

In that case the EDRAM of the X360 is an order of magnitude faster -bandwidth wise, I am not talking about latency- than the eSRAM on XBO.

More concretely 150% faster, if my maths aren't wrong, that's why I mentioned an order of magnitude.

These differences and the emergent realities of eSRAM vs EDRAM have forced rearchitecting the entire console.
But an order of magnitude is 10x. Also the BW to eDRAM in Xbox 360 was 32GB/s? So less than 1/3 compared to the SRAM here.
 
Suppose you got a call from someone important, and you decided to expand the Skype call fullscreen.

You don't want to be kicked off a multiplayer server just because you decided to answer a Skype call, do you?

So would your avatar qte to talking on a cellphone with a finger up indicating just a minute?
 
can someone explain the 10% GPU reservation and the 6 cores ? i am having a hard time keeping up with all that.thanks?

will the GPU now be 1.1tflops just for games?
 
The 10% GPU reservation is pretty bad news. Not just because of the lost GPU time itself but because that means what developers were already warning about is probably true.. more API abstraction than on PS4. You can't get very close to the GPU when you don't even have exclusive access to it.
 
Exactly. there is a huge diffrence between a 200-400 mhz bump on the cpu and a 200mhz bump on the gpu portion of the apu than a 3-4 times increase in clock speeds.

We don't know the tipping point of when yields go to hell vs clock speeds.

Its fair to say we don't know the tipping point but its also fair using that logic to say the manufacture knows which is why we have the clock frequencies we have now.....
 
The 10% GPU reservation is pretty bad news. Not just because of the lost GPU time itself but because that means what developers were already warning about is probably true.. more API abstraction than on PS4. You can't get very close to the GPU when you don't even have exclusive access to it.
The 360 also had a GPU reservation, somewhere around the 10% mark, might have been a bit less. Developers had no problem getting close to the metal there.

They are using VMs, the host OS manages access to all hardware, it is all virtualized from the game OS perspective. That's also how they take care of the constrained state. There are 6 virtual cores available to the game, normally they're mapped directly onto 6 physical cores. When you go constrained, the VM folds two of the virtual cores onto two others, so now 6 virtual cores are mapped to 4 physical cores. The game gets notified and can move threads if it feels it needs to, but even if it doesn't, the game will still run, but slower.
 
What was the nature of this GPU reservation on XBox 360? It's the first I'm hearing of it.

You can virtualize CPU time, but that means partitioning a fixed amount of resources (in this case two cores). Virtualizing the GPU is another story..
 
If the OS does any sort of notification or overlay it has to reserve some GPU time. It doesn't need to be constant but there has to be a maximum.
 
If the OS does any sort of notification or overlay it has to reserve some GPU time. It doesn't need to be constant but there has to be a maximum.

Sure, but doesn't the game get paused when that happens on XBox 360? So it wouldn't take away from its total GPU budget or interfere with its ability to access the hardware directly.

If that happens w/o pauses on XBox One that seems like the perfect kind of thing to use those hardware overlays for, and not mess with the GPU at all. Even on XBox 360 it's not like it had to use the GPU to render the menus and stuff (since the GPU doesn't manage the framebuffer anyway), they could have probably done that in software too.
 
Worse you might be acting as the multiplayer server, and you don't want to DC everyone else just because you answered a call.

I maintain that if they're going the VM route they should simply open another VM when acting as the multiplayer server.

And I thought they're promising dedicated servers in the cloud already?
But of course that doesn't mean you can't act as a server anyway so probably a moot point.
 
Sure, but doesn't the game get paused when that happens on XBox 360? So it wouldn't take away from its total GPU budget or interfere with its ability to access the hardware directly.

If that happens w/o pauses on XBox One that seems like the perfect kind of thing to use those hardware overlays for, and not mess with the GPU at all. Even on XBox 360 it's not like it had to use the GPU to render the menus and stuff (since the GPU doesn't manage the framebuffer anyway), they could have probably done that in software too.

Notifications like so and so just signed onto XBox Live.
Video chat overlays.
If the OS draws on the screen it needs some portion of the GPU to do it and 10% isn't totally out of line with what I would expect.
 
The 10% GPU reservation is pretty bad news. Not just because of the lost GPU time itself but because that means what developers were already warning about is probably true.. more API abstraction than on PS4. You can't get very close to the GPU when you don't even have exclusive access to it.

The bad technical news just doesn't stop concerning the XboxOne. With all the leaked overhead its starting to feel that One is about half as powerful as PS4 in overall raw gaming power. The physical design doesn't inspire either. It's going to be interesting how the public reacts and the pricing. I'm surprised more devs aren't speaking up positively or negatively concerning these systems. Damn NDAs
 
I maintain that if they're going the VM route they should simply open another VM when acting as the multiplayer server.

And I thought they're promising dedicated servers in the cloud already?
But of course that doesn't mean you can't act as a server anyway so probably a moot point.

From what I saw, the intent is not to provide multiple running game VM's but rather provide something very lit weight to the game. Much like 360 where the bulk of the game OS is statically linked to the application.
So you basically always have exactly 2 VM's running, one for the game and one for the App OS, the latter of which can be running multiple applications.

I personally am assuming there is some cost to using the cloud compute, so I think you'll still see p2p multiplayer games. The easy solution to keeping the other players in the game if you answer a Skype call, seems to me to leave your game instance running in the VM. You no longer need to render or animate anything, so there is probably plenty of performance on 4 cores to keep it running.
 
Status
Not open for further replies.
Back
Top