Xbox One (Durango) Technical hardware investigation

Status
Not open for further replies.
You can't not reserve memory BW, so it doesn't need to be explicitly specified. That is, for every clock the processors are working on the system, they can't be accessing the RAM for the game, which means those clocks of RAM access are lost to the game, regardless of whether the processors are actually consuming data or not. Or, if the RAM is capable of 2133 million transactions per second, and the processors are tied up for 10% doing system stuff, you can't then access the RAM 2133 million times in the remaining 90% of the second for the game.

I really don't see that separating out "bus time" and "GPU time" is useful, as they appear to be one and the same in Xbone. Similar thing for CPU, But even more so in the GPU as the esram BW is tied to the crossbar that is in some way tied to the ROPS which is tied to the clock and therefore the timeslice.

If you're doing a BW limited operation on the GPU then it's absolutely true to say that with a timeslice increase that your performance is increased due to a bandwidth increase. Because an increase in MBs of data transfer directly correlates to an increase in work done.

The mental gymnastics involved in claiming that being able to transfer more data per frame in a data-transfer limited operation is not equal to an increase in BW is puzzlingly insane, like a girl dumping you because "she just likes you too much ".

Fuck her, she probably just said that because you don't make out with her like her brother used to.

Anyway, I should end on the point that is *is* possible to reserve memory BW using a QoS approach, but that I've never seen any indication that 1Bone is using this. But I still had to say this.
 
In terms of the GPU, reserving 10% GPU time but reserving no main ram bandwidth to feed it would seem ... odd .. seeing as it's doing nothing without main memory.

I don't think one specifically reserve the bw. It's more like no other proc can use it at that moment, so it's just a given when context switch happens.

Given that the SDK disables the always-on skeletal tracking, it's probably natural to have more 'time' on both GPU and CPU.

Does anyone what multitasking scheme the X1 falls under? Or the hypervisor basically took care of it with resource allocation?
 
I don't think one specifically reserve the bw. It's more like no other proc can use it at that moment, so it's just a given when context switch happens.

Given that the SDK disables the always-on skeletal tracking, it's probably natural to have more 'time' on both GPU and CPU.

I think you're right.

My guess is that you don't reserve the BW, but that you reserve the processing capacity which effectively reserves the BW ( I see these things as effectively equivalent).

Without any evidence to prove this, I think it's most likely that Bone OS reserved 10% of the GPU and CPU, effectively reserving 10% of both esram and main ram BW, but that with the release of the GPU time to the scheduler the esram BW was as a matter of course released and this meant that it was free to draw from main ram BW at all times too.

I suspect - though I have nothing to support this - that a few percent (5%?) of CPU time is still reserved, though as the GPU can now access main memory simultaneously that the main memory BW is no longer effectively as reserved.

I could be pulling this from my ass though, like a giant tape worm. *shrugs*

Does anyone what multitasking scheme the X1 falls under? Or the hypervisor basically took care of it with resource allocation?

I don't, but it would be interesting to know if the Bone hardware were capable of a QoS like approach to memory BW reservation rather than just timtimeslice.
 
I suspect - though I have nothing to support this - that a few percent (5%?) of CPU time is still reserved, though as the GPU can now access main memory simultaneously that the main memory BW is no longer effectively as reserved.

Context switch is not free though, neither is the hypervisor. You do get the screen snapping 'for free' but it's nothing is ever free ;)
 
well, there could be different reasons, why those benchmarks were faster. even the OS is not the same, so maybe this had something to do with it.
if really 5% of the cpu was reserved, there could also be a small indirect bandwidth reservation for the caches and main memory. also, if you reserve 5% of the cpu cycles, you may effectively loose more than those 5%. Threads must get resynced, maybe caches rebuild, ...
I've always assumed that the reserved 2 cores were feeding the gpu-processing and not another reservation of all cores.

A global 5% reservation in addition to the 2 reserved cores makes no sense. The difference is almost certainly due to inefficiencies and overhead related to the OS virtualization. Being 10% slower at a task despite a 10% clockspeed advantage points to a significant handicap.
 
I wonder if part of the motivation for the upclock came from multiplatform developers complaining about how the Xbox One CPU couldn't keep up with the PS4 when they didn't expect any difference. That it was an explicit attempt to overcome the inherent deficit created by the 3 VM OS choice.
 
How heavy weight are the services which run on the 2 reserved cpus? Wouldn't surprise me if the L2 or memory bus is more stressed than on a PS4. I doubt it has anything to do with virtualization itself for generic code.
 
I really don't see that separating out "bus time" and "GPU time" is useful, as they appear to be one and the same in Xbone.
Right, that's what I was saying. Notice the double negative. It is not possible to reserve processor time without also reserving memory time/BW in the same time slice, because you have no processors to use that BW. So as you say -

My guess is that you don't reserve the BW, but that you reserve the processing capacity which effectively reserves the BW ( I see these things as effectively equivalent).

And to explain the double negative.
"We will reserve the processor time but not the bandwidth and leave the full BW available to games."
"You can't do that."
"Not reserve the BW?"
"Yes. You can't not reserve the bandwidth."

:D
 
Is there any clue, what the 8 GB Flash memory is used for?
The OS seems to be on the HDD, else it should boot up much faster (windows on my normal drive boots up faster than the xbox one (cold boot)). Right now I don't see any point for having it built-in, because it is not the cheapest component, but it seems as it is unused right now.
 
Flash memory isn't intrinsically faster than HDDs. It has intrinsically faster access times, but can have lower load speeds. Depends entirely of the flavour of flash used. It's quite possible the OS sits on flash but takes a while to load. eg. Take an Android device and cold-boot it. Takes a long time to get going despite loading off flash memory.
 
If I remeber correcly, the 8GB is used only for mantaining the state of the open but not used app
for example you are watching a video, then open a game, then return to the video
 
Let me elaborate: They (anandtech) measured iPhone GPU/CPU throttling by doing a specific benchmark while reading the power draw.
When the power draw went down, the benchmark results went down as well, maybe we can do something similar on the Xbox One?
 
Last edited by a moderator:
Right, that's what I was saying. Notice the double negative. It is not possible to reserve processor time without also reserving memory time/BW in the same time slice, because you have no processors to use that BW. So as you say -

My guess is that you don't reserve the BW, but that you reserve the processing capacity which effectively reserves the BW ( I see these things as effectively equivalent).

And to explain the double negative.
"We will reserve the processor time but not the bandwidth and leave the full BW available to games."
"You can't do that."
"Not reserve the BW?"
"Yes. You can't not reserve the bandwidth."

:D

Oops!

I can't believe I wasn't able to not misunderstand that. :oops:
 
Flash memory isn't intrinsically faster than HDDs. It has intrinsically faster access times, but can have lower load speeds. Depends entirely of the flavour of flash used. It's quite possible the OS sits on flash but takes a while to load. eg. Take an Android device and cold-boot it. Takes a long time to get going despite loading off flash memory.

So this, a major problem with Win8 Atom based tablet devices is that they all use eMMC rather than an SSD, eMMC is optimised for low power draw and has much lower peak read/write than flash chips arranged in an SSD (I've seen peak writes top out at 30MB/s, reads at ~50MB/s). That sounds good but in reality when you team that with MS updates reading and writing hundreds of small files individually you're looking at ~20-30 hours for a raw Win8.0 install to be fully patched (and that's excluding the Win 8.1 upgrade).

As for the 8GB flash in XB1 could it be a scratchpad for the RAM state to speed up system resumes? Or do the XB1 and PS4 just Suspend to RAM instead? Other than that I'd imagine it has a 'service O/S' for advising the user when the main hdd breaks?
 
PS4Bone are so similar that I think the most interesting difference this generation (Kinect aside) is the esram and the extent to which that will - or will not - allow Xbone to operate more efficiently.

With the GPU reserve seemingly gone, and the likes of DF offering metrics on sometimes identically featured games, we might be able to infer some interesting things in the coming years.
 
I wish the X1 would support Readyboost through USB 3.0. It would allow a small and cheap SSD for caching and large slow HD solution for a reasonable price.
 
I wish the X1 would support Readyboost through USB 3.0. It would allow a small and cheap SSD for caching and large slow HD solution for a reasonable price.

What for? There are 8GB of flash inside the console for that..
 
Status
Not open for further replies.
Back
Top