Xbox One (Durango) Technical hardware investigation

[mrcorbo]

Flushing a cache selectively doesn't change the overall result. The case where the whole cache is marked volatile is the same as a total flush, and in the case where there is mixed data, flushing data that isn't coherent doesn't change the outcome, just the performance cost to ongoing graphics work to some variable degree.

That would seem to be the whole point, though, no? One setup is better than the other because it enables better performance.

 

[3dilettante]

That would seem to be the whole point, though, no? One setup is better than the other because it enables better performance.

There isn't an arbitrary FPS limit defined for whether something is hUMA or not.
How is the end result different?

 

[mrcorbo]

There isn't an arbitrary FPS limit defined for whether something is hUMA or not.
How is the end result different?

It's AMD's nomenclature. If a part of their definition of hUMA is having the capability to partially flush and re-populate cache with compute data I wouldn't find this to be any different than the functional requirements I've seen for compliance with various APIs.

 

[3dilettante]

It's AMD's nomenclature. If a part of their definition of hUMA is having the capability to partially flush and re-populate cache with compute data I wouldn't find this to be any different than the functional requirements I've seen for compliance with various APIs.

hUMA is an AMD evangelization term, and that evangelization hasn't drilled down to that level.
The more robust definition is the memory model for HSA, which has a very low bar to get over to be considered coherent.

If non-coherent data gets flushed on occasion, how is it relevant to the question of whether coherence is maintained? That's an implementation detail of the other device.

 

[zupallinere]

More info:

After sending some emails to our representatives at AMD I was told that "Kabini doesn't support hUMA" which is the APU that both the PS4 and Xbox One processors are based on. AMD further clarified with us:

Our spokesperson made inaccurate statements about our semi-custom APU architectures and does not speak for Microsoft, Sony or the AMD semi-custom business unit responsible for co-developing the next generation console APUs.

From: http://www.pcper.com/news/General-T...S4-will-NOT-utilize-AMD-hUMA-Kabini-based-SoC

So a blanket statement about consoles using kabini and since that is the case neither uses hUMA per se. How either system goes about doing hUMA-like things is another story. The gut says that Sony chose a path similar to AMD, while MS does things in a way that helps things in terms of it's particular design. One aspect being that One is supposed to THE One input so there maybe coherence issues that crop up in the XB1 by nature of it's multifunctionality that won't in the PS4. The MS architect mentioned "server" stuff and virtualization as some of the drivers of the coherence issue.

Added: of course AMD maybe saying nothing at all since neither system is using Kabini itself for sure so "which is the APU that both the PS4 and Xbox One processors are based on" is a presumption Of course AMD is quoted as saying "inaccurate statements" were made and the spokesperson can't legally speak for anything going on anywhere else. C't's response will be greatly appreciated

 

[3dilettante]

That would make more sense than some hair-splitting that can differentiate between the two architectures.

 

[mrcorbo]

hUMA is an AMD evangelization term, and that evangelization hasn't drilled down to that level.
The more robust definition is the memory model for HSA, which has a very low bar to get over to be considered coherent.

If non-coherent data gets flushed on occasion, how is it relevant to the question of whether coherence is maintained? That's an implementation detail of the other device.

This is increasingly becoming a devil's advocate type argument on my part, especially since the point seems to be moot, but...

I think performance is always relevant. If a specific feature allows for more efficient usage of a given set of compute resources I would see no issue with AMD using it as a criteria to determine hUMA/not hUMA.

That having been said; I am, of course, willing to accept your description of how AMD is using the term "hUMA" over how I am speculating that they could be.

 

[dobwal]

More info:



From: http://www.pcper.com/news/General-T...S4-will-NOT-utilize-AMD-hUMA-Kabini-based-SoC

So a blanket statement about consoles using kabini and since that is the case neither uses hUMA per se. How either system goes about doing hUMA-like things is another story. The gut says that Sony chose a path similar to AMD, while MS does things in a way that helps things in terms of it's particular design. One aspect being that One is supposed to THE One input so there maybe coherence issues that crop up in the XB1 by nature of it's multifunctionality that won't in the PS4. The MS architect mentioned "server" stuff and virtualization as some of the drivers of the coherence issue.

Added: of course AMD maybe saying nothing at all since neither system is using Kabini itself for sure so "which is the APU that both the PS4 and Xbox One processors are based on" is a presumption Of course AMD is quoted as saying "inaccurate statements" were made and the spokesperson can't legally speak for anything going on anywhere else. C't's response will be greatly appreciated

Outside of the console parts being jag and GCN based, what supposedly makes the consoles kabini based? You could say Kaveri is Kabini based if you ignore the differences between the apus which is probably aren't as big as the differenceS that exists between AMD apus and the chips in the consoles.

 

[scently]

It would appear to me that these two quotes throw the entire idea of the Xbone being HSA Coherent / GPU<->CPU cache coherent or hUMA out the window completely, but I could be wrong.

You should also highlight these places:

"The GPU can perform both coherent and non-coherent memory access. Coherent read-bandwidth of the GPU is limited to 30 GB/s when there is a cache miss, and it’s limited to 10 – 15 GB/s when there is a hit. A GPU memory page attribute determines the coherency of memory access."

and

"The GPU has a direct non-coherent connection to the DRAM memory controller and to ESRAM. The GPU also has a coherent read/write path to the CPU’s L2 caches and to DRAM."

 

[zupallinere]

Outside of the console parts being jag and GCN based, what supposedly makes the consoles kabini based? You could say Kaveri is Kabini based if you ignore the differences between the apus which is probably aren't as big as the differenceS that exists between AMD apus and the chips in the consoles.

Ah here in the comment section of the PC Perspective article the author says:

It may support some kind of custom memory architecture but I was assured that the definition of hUMA leaves Kabini-based designs out.

 

[Kaotik]

Outside of the console parts being jag and GCN based, what supposedly makes the consoles kabini based? You could say Kaveri is Kabini based if you ignore the differences between the apus which is probably aren't as big as the differenceS that exists between AMD apus and the chips in the consoles.

Console APUs share both CPU & GPU "base"architectures with Kabini, Kaveri doesn't.

 

[dobwal]

Console APUs share both CPU & GPU "base"architectures with Kabini, Kaveri doesn't.

oops forgot the part about jag versus SR.

 

[Gipsel]

Well according to some documentation, there is 1TB of Virtual Memory Address Space and that a page can be in ESRAM,DRAM or unmapped. So if you tell the CPU to fetch something from a virtual address, it shouldn't matter if it's actually in the DRAM or ESRAM. You could actually pass pointers between CPU and GPU .

It doesn't matter for the GPU, that's clear. But accessing an address currently mapped to the eSRAM from the CPU side could still always raise a memory access violation exception and simply return nothing. Being in the same address space doesn't mean it's (directly) accessible.

Console APUs share both CPU & GPU "base"architectures with Kabini, Kaveri doesn't.

The more important question would be, if they share the northbridge design with Kabini or Kaveri . There happens this coherency stuff.

 

[dobwal]

You should also highlight these places:

"The GPU can perform both coherent and non-coherent memory access. Coherent read-bandwidth of the GPU is limited to 30 GB/s when there is a cache miss, and it’s limited to 10 – 15 GB/s when there is a hit. A GPU memory page attribute determines the coherency of memory access."

and

"The GPU has a direct non-coherent connection to the DRAM memory controller and to ESRAM. The GPU also has a coherent read/write path to the CPU’s L2 caches and to DRAM."

That seems to hint that Xbox one hardware makes use of onion as well. I assume that a cache hit is service by the 10-15 GBs of bandwidth over the onion bus, while a cache miss is serviced by 30 GBs of bandwidth the cpu has available to RAM.

I'd bet that the PS4 and XB1 is sporting the same arch where the Sony favored more CUs while MS favored more local memory. I find it doubtful that AMD would restrict HSA implementation on consoles. Why? Having HSA on consoles would validate the point of the HSA foundation and its intention. Its not like HSA is some proprietary tech AMD wants to keep to itself. Its royalty free and is being pushed to be an industry standard. How does restricting it from MS and/or Sony accomplish that goal?

If one is sporting hUMA while the other does not, it more than likely a case of MS or Sony choosing an alternative solution that aligns better with their design. Im willing to bet hUMA was readily offered to both manufacturers for cache coherency needed for an HSA compliant design.

 

[Cyan]

The problem is that the article in question didn't make that distinction, and by not doing so it created the impression of a performance deficiency in the X1. It was the headline of this article and what the journalist (if you want to call him that) wanted to draw attention to. So I would say that it was intentional on the magazine's part to spin this bit of information against the other platform.

This is why company figures have to be careful who they sit down and grant interviews with. I can imagine that the AMD rep's answers were alot more thorough than what the article represents, but it appears the person he spoke to probably went on a cherry picking expedition.

It isn't the first time it happens and it won't be the last. I don't know. Just a hunch, I suppose.

Similar things can happen even with some gaming media like Eurogamer -which I like and respect A LOT, I love the site basically-.

i.e. They made an almost 100% literal transcription of John Carmack's words, except for the fact that they removed/modified certain comment from him talking about current generation hardware.

http://www.eurogamer.net/articles/2013-08-02-carmack-says-next-generation-is-anyones-game

They didn't want to get into trouble, I guess.

However, if the bad news is related to Xbox One nobody cares, there is no problem and it's ridiculously up to everyone's free will.

It's fine though, it's way better than having people just posting bad news about the Xbox One whenever they can. Sometimes you have to wonder what they are trying to accomplish with that.

Gaming is simple, you either have fun or you don't. I played Defense Grid: Awakening today and had lots of fun, and it made me wonder what's the point of writing negative things in forums about other platforms when you could be playing a fun game instead.

 

[zupallinere]

It doesn't matter for the GPU, that's clear. But accessing an address currently mapped to the eSRAM from the CPU side could still always raise a memory access violation exception and simply return nothing. Being in the same address space doesn't mean it's (directly) accessible.
The more important question would be, if they share the northbridge design with Kabini or Kaveri . There happens this coherency stuff.

Yes all these, northbridge, esram, bus and cache coherency issues are going to be the big things that you can really chew over because they are the biggest differences between the systems and because bandwidth, generally speaking, is always going to be the gate for performance in any console or computer in general. In fact how these consoles, like the XB1 deal with bandwidth is going to give these systems some legs when it comes to competing with PCs.

CPUs and GPUs get so fast so quickly that there isn't as much interest ( or need ) in new ways of shuttling or not shuttling data around and of course legacy issues usually restrict major changes in the way bandwidth is dealt with in any case.

Now that I think about it simply HD resolutions are a bandwidth issue and one that favors consoles for a few years at least. All they have to do is make 1080 look great.

Added. Yes newer [CG]PU designs are also part of the bandwidth solution I'm just saying ... when you increase the FSB speed you get a bigger bump per cycle is all.

 

[Docwiz]

I just don't think huma is a problem and I think there are some people that are looking for problems where there are none....

I know some of this has been posted, but I wanted to post the entire thing for a good reference so everyone can see the entire quote because I think it's important. I have also linked the sources so you can see how I got the text. This is from the Microsoft Xbox One Architecture Panel on May 21st, 2013.

Boyd Multerer (Partner Director Of Development, ISS Console Development)
Source: http://www.youtube.com/watch?v=vg_DR0leAYw
20:15

"This next-generation of GPU is.... it is kind of a break from the last generation of GPU which were very microcode optimization-sensitive.

You know, the exact order of the code and the shaders made a huge difference in how fast they ran. This time, the chip architecture is based on supercomputer-like technologies and is much more about data flow. Having the right data in the right caches in the right places at the right time is what will make all the difference in the world for taking advantage of these chips.

It's relatively easy to get your code ported onto it. It's relatively hard to get it optimized and really, really looking good, and we worked really closely with Nick's team to make sure we had really good caches on the die, ready to feed the GPU, and that was a really important partnership."

Nick Baker (Engineer Console Architecture)
Source: http://www.youtube.com/watch?v=vg_DR0leAYw
21:50

"We had to invest a lot in coherency through the chips. There's been I/O coherency for awhile, but we really wanted to get the software out of the mode of managing caches and you know, put in hardware coherency for the first time on a mass scale in the living room on the GPU."

Boyd Multerer (Partner Director Of Development, ISS Console Development)
Source: http://www.youtube.com/watch?v=vg_DR0leAYw
37:35

Speaking about "Major" changes on console generations. (I.E. Ethernet Port for original Xbox, HD graphics for Xbox 360, and Changing Architecture for XB1)

NOTE: Speaking about a second "Major" change on the XB1, besides the Cloud based Architecture evolution of the XB1

"We could also go on about how the supercomputing-style architecture makes some changes. There's going to be different ways you're going to build your games."

 

[Ekim]

So today is the Xbox One Silicone session at Hot Chips right after AMD talking about Kabini. Any guesses what will be revealed?

 

[Brad Grenz]

rub your Xbox One's belly and a genie comes out!

 

[Ekim]

How many wishes?