Understanding XB1's internal memory bandwidth *spawn

As Shifty said, both would have influenced their decision to use esram. The fact that Microsoft already has a lot of experience with embedded memory and no doubt had lots of ideas on how to expand on and improve that solution would no doubt have influenced them to go with it. However I still maintain that ultimately the deciding factor would have been the requirement to have a large main memory pool. If the XB1 was only ever going to target 2GB of main memory then I think they'd have been far more likely to just go with a high speed GDDR5 interface and be done with it. Afterall, all the improvements that the esram brings in usability over the edram are only aimed at reducing the useability deficit of such a memory configuration compared to a single pool of high speed memory.

The other 2 potential benefits are bandwidth (which according to the initial spec was only going to be on par with a fast pool of GDDR5 anyway) and latency - which the engineers practically went out of their way to avoid talking about.

Your argument hinges on the fact that they would have designed the XB1 by looking at the XB360 design and evolving it (which no doubt would have been part of the equation). But technology is different today than it was in 2005. In 2005 if you wanted high bandwidth from a single memory pool without embedded memory you'd have had to use a prohibitively expensive 256bit memory interface. Today, that's a viable option and so the correct high level choices for 2005 would not necessarily be the correct high level choices for today and thus some element of 'going back to the drawing board' would certainly have been required.

My point in asking for that level of detail was to specifically prevent a vague reference being held up as proof of some kind of notable esram latency advantage.

The vgleaks article does reference lower latency. But do we know that's come directly from Microsoft and isn't just a VGleaks assumption about embedded memory? And even if it does come direct from Microsoft, without specific numbers and in light of the downplaying of any latency advantages in the recent interview, how do we know that the stated advantage is significant?

Which in an interview specifically aimed at extolling the advantages of the XB1 architecture is extremely telling IMO.

I think the key word there is potential. Those guys obviously know what they are talking about so if they say there's a specific advantage of a low latency embedded memory solution then you can take that to the bank. However I don't think anyone has said there is an advantage so far. Merely that if the memory is truly low latency enough then it would have these advantages. The key is whether that low latency is real and it's now starting to look as though it may not be. At least not to a significant enough extent to be notable when questioned about it's performance adding potential.

The highlighted part of that quote (below) has me a little confused. Are they talking specifically about low latency memory or are they talking generally about the latency hiding abilities of GPU's (large number of threads etc..) being the key performance driver for this particular GPGPU application?

 

I agree entirely with this part. I am likewise arguing that the context of how this decisions to include eSRAM was made radically colors the interpretation many online have about the design considerations MS has made. I want to apply pressure to those whose posts reflect a narrative that gets spun into something it isn't, since that may improperly color the discussion's context going forward.

It's not cut and dry. He just says they haven't talked about it one way of the other. If that was all the info we had, I'd agree. But we also have the info from the leaked dev docs and it would seem some programmers on the forum here were easily able to think up uses for exploiting it. All of this taken together doesn't explain why Baker didn't talk about it, but it DOES suggest that we shouldn't take his response as ending that discussion. If he had come out against it I would err on the side of caution and lean towards the DF interview. But he didn't do that either, so to me it's still up in the air.

It could also be something the software guys would look to exploit whereas Baker is a hardware guy. The MS patent I referenced earlier was software-based, ERP/sebbbi are software guys obviously, so perhaps it's a potential benefit that played no role in Baker's views on its inclusion. Goossen (another software guy) noted its utility with Kinect, for instance.

I quoted the dev docs. So yes, we certainly do have MS saying as much. It's also cited by Goossen vis a vis Exemplar/Kinect. I think you guys should pay more attention to the entire interview and not focus only on that singular quote and Baker's short response.

For Kinect it does. It is explicitly cited by Goossen in the article.

 

You're wrong. Read their Example (typical game scenario) again:

http://www.eurogamer.net/articles/digitalfoundry-the-complete-xbox-one-interview

 

They were "originally" considering something with 4GB of DDR4 RAM, as per Yukon. I'm not saying that's something they really dug into in a serious fashion, but it was under some sort of consideration prior to 8GB of DDR3. If the agenda at that point was tons of cheap RAM, 4GB of DDR4 isn't really fitting the bill imho. It doesn't fit in well with either of those goals. Yet, even at that point in mid-2010 they were already settled on embedded RAM.

They wanted AT LEAST 32MB of either eDRAM or eSRAM, as per the Yukon leak. So I can't agree with you here. Which is fine. We can agree to disagree. Just noting that we actually do have a specific data point to work with that shows they were already committed to embedded RAM prior to "lots" of "cheap" RAM becoming decisive for their goals.

We could ask bkilian about that perhaps, but I do recall him saying in the past that it was pretty much verbatim. Their PS4/Orbis articles lately would bear that out to a tee as well, where they showed their info from their older articles came verbatim from Sony's dev docs and there was no paraphrasing on their part really at all as best anyone can tell.

See my comment to Shifty on that. It could well be related to the question being posed to a hardware guy and latency not being a major aspect of the eSRAM's inclusion from his pov, yet for software guys it may be obvious how to exploit it in meaningful ways. The patent I noted was software-based, Goossen noted a Kinect software application that you seem to ignore for whatever reason, ERP/sebbbi offered their own ideas as software guys too iirc. I'd be more willing to let that go if Baker had outright killed it in his response but he doesn't even address it at all, one way or the other. So are we to ignore Goossen and the dev docs in light of Baker's response? I say no. Instead I'd like to see DF press a software guy there on that specifically.

Like I told Shifty, I'd agree if there weren't other reasons to cautiously avoid that conclusion already out there.

Seems to say Exemplar needs quick memory fetches to work efficiently. Bear in mind the part you bolded was DF's commentary, not Goossen's.

 

A fair argument, but I'll add that discussion has be mostly hypothetical. The likes of ERP and Sebbbi are theorising benefits (well, Sebbbi could be talking from experience!), and that was predicated on an understanding that 'low latency' meant 'low latency' which, I repeat, we still don't know what latency the ESRAM actually is. It's an unqualified term. For some people, it means an order of magnitude lower access latency. For others, it could be 20% lower latency. Without any idea how many ns/clock cycles we're actually talking about here, it's hard to discuss the impact of ESRAM's latency.

Well I haven't read the article yet shock so I may have missed something. But I'm talking about the 'whole picture'. We have...

...from a long time ago. Now we have no further discussion on that in this remarkably open and in-depth interview. Why no word on the advantages of the low latency ESRAM in CB and DB performance if they really benefit? It doesn't make sense to miss out an advantage like that in this interview. Surely the response to Leadbetter's question would be more like...

I cannot reconcile the response with any graphics advantage.

I'm reading that differently to you...

...means, "using GPGPU for Kinect required more managing the GPU's innate latency-hiding memory systems than using massive parallel FPU throughput." I don't see anything there saying a low latency memory store is beneficial to GPGPU above and beyond what GPUs are used to working with.

 

I think we've both put our arguments forward sufficiently at this point and there's no point beating this one over the head until further evidence presents itself. I did however just want to point out one thing from your post above, and thats that Goosen was present throughout the interview. He had as much opportunity to respond to that question as Baker did (more than once they both gave their own perspective on the same question) yet he chose not to. That should count for something.

 

The part about GPU hiding latencies is DF's commentary, not Goossen's.

 

I'd like to make a point guys that DF only had the one phone call interview with Baker & Goosen & they have decided to release it piecemeal. MS are beholden to DF & Richard to release the details of that interview & so far we can't be sure how much he's released. MS has no control of what or when they release it. This is one reason why I wished they had recorded a video of the interview. As it stands there is doubt as to what came out or didn't come out of that interview.

Tommy McClain

 

So....you are willing to ignore the dev docs and Goossen's explicit note about Kinect utilizing the low latency, two reliable facts presented to you, in favor of your own interpretation of what someone else could have said in a given opportunity?

You and Shifty are both on the wrong side of the logic here guys. I understand skepticism and share it in terms of wanting more details, but you can't rationalize swapping out reliable facts from the horse's mouth with your own circumstantial efforts to read between the lines. Come on now.

Simply noting how odd it was that they didn't go into detail on the matter doesn't magically erase the dev docs nor Exemplar's utilization.

I also found this quote that we both missed, though not necessarily referring to eSRAM at all, but worth noting:

And another from Goossen:

Idea's what they are referring to in those quotes?

The more I re-read Baker's other comment the more it sounds like he is referring moreso to GPU utilization and not eSRAM. DF opens their statement noting discussions online about eSRAM latency, but the other sentences are about GPU handling latency which is what Baker directly responds to. So I'm growing more apathetic to the assumptions that he was directly addressing the eSRAM latency. Seems more like he merely confirms how most GPU's are designed, including X1's.

 

DF claims the latest article was the full transcript.

 

What do you mean with running an actual title?
An actual title will never use continously 150+GB/s of eSRAM bandwith or it means it looks to be severely bandwidth limited (as the requirements usually spike a lot over the course of a frame).
Furthermore, it gets really hard to quantify the used bandwidth exactly outside of slightly more synthetic tests as a lot of factors kick in like the often quite efficient Z compression (that works also without MSAA) and caching in the ROPs for instance. And for a real game you have also likely overdraw from the same batch of geometry at some times during your rendering where the ROP caches can help a bit to reduce the external bandwidth requirements. Or an early Z test kicks the fragments out of the pipeline even before the pixel shader! For texture or buffer accesses it is even more important as the relevant caches are larger. You basically need synthetic test cases to minimize the effect of the caches and other "efficiency helpers" in the GPU to get reliable bandwidth numbers. Otherwise you measure a blend of cache bandwidth and external bandwidth. You can compare that with the latency measurements on CPUs where the prefetchers got smarter and basically broke a lot of the latency benchmarks at some point. While this is of course good for the performance (as they also work in real software), it may tell you not everything about latency or bandwidth in this case (and the PS4 has more/larger caches).

The problem is that everything is more complicated in the real world.
One simply can't give an simple average as it varies a lot with the use case. And if one makes up some conditions to derive some kind of "average" it will be a not very meaningful number, as under different conditions it will look different. And taking one game isn't going to help much, as another one using different rendering techniques will have different needs. And as devs will tune their engines to use what is there, this will probably lead to a shift in the observed "average".

Edit:
Sorry Shifty. I guess it should have gone to the other thread?

 

No, I already addressed both of those in a previous post. And it seems to me that it's you that's applying a specific interpretation to both of those sources to suit your world view. An interpretation which you state as fact but is at best debatable.

You've made your view quite clear Astro. It clearly isn't shared by everyone and is certainly not as factual as you try to imply it is. So why don't we just agree to disagree and move on.

It's a little more than odd and while not in itself proof that there are no major latency advantages, it certainly raises serious doubts about that argument.

Regarding your other two sources, as mentioned in earlier posts, one is a generic statement with no specific metrics given to indicate significance which may or may not have been VGL's own speculation and the other could quite easily have been a reference to the GPU's natural latency hiding qualities (your factually stated opinion to the contrary not withstanding).

It seems to be quite clearly talking about the advantages of an APU with shared memory and not specifically low latency esram.

Saying that latency was one of the design aspects they considered is hardly proof or even particularly useful evidence of the esram having game changing low latency. Latency is a problem that must be addressed in almost every aspect of the system and it's no surprise that they would have worked to keep it to a minimum in every area. It doesn't specifically mean that they implemented a very low latency embedded memory pool.

And in fact, if that is what it meant, then why didn't Goossen jump in and say that when that specific question was asked?

 

Thanks for the dive. I see where you are coming from and we do agree about dev to dev and further tuning.

 

An enumeration that includes frame rate, user interface interruptions, and latency... it looks like that latency is in milliseconds, about human perceivable latency. They are trying to correct the huge latency issues of kinect-1? Perhaps?

 

If bandwidth is measured in actual games it's invalid. (and ms pr & fud)
If bandwidth is measured using synthetic tests it's invalid. (and ms pr & fud)
So any takers for a third way also? (and ms pr & fud)

 

Awww. My bad. Seems like doing to the first couple of articles before the full transcript didn't help MS out so much(first impressions and all), but I guess it helped DF get some much wanted traffic.

Tommy McClain

 

How about numbers from MS when on a PR junket are not gospel? They are playing up their strength and talking down their weakness, as they should . Don't expect to get any specific information from them, it is not in their interest. The same is true for Sony. Wait for developers to talk off the record.

 

Maybe? Hard to glean anything about what kind of latency is being referenced there but that could well be it for Goossen's quote. They did mention it was lower (VGLeaks says down to 60ms for Kinect, HotChips suggests 20ms but unsure what that figure is actually referencing).

 

As Shifty once said, you don't have to respond to people all the time. So I'll leave it at that

 

Applying this logic to the PS4 leads us to abandon absolutely all known info about these machines without prejudice. Congrats, you've taken us back to the stone age of 2012.