esram astrophysics *spin-off*

Status
Not open for further replies.
He was responding to a question, not Internet ramblings. So it is open to interpretation.

Yes, and that question was explicitly about bottlenecks and eSRAM, seems pretty clear what was being asked. Let's look at what the article says "I asked him if Capy had noticed any performance bottlenecks while working on the Xbox One. Specifically Microsoft’s use of ESRAM."
 
Yes, and that question was explicitly about bottlenecks and eSRAM, seems pretty clear what was being asked. Let's look at what the article says "I asked him if Capy had noticed any performance bottlenecks while working on the Xbox One. Specifically Microsoft’s use of ESRAM."
Yeah, but it ultimately does come down to what many people here said: If your game doesn't push the hardware that much anyway, i.e. does not require much more than the basic ~68MB/s DDR3 memory speed to start with, the eSRAM bandwidth is just an additional "icing-on-the-cake" option to optimize your game to run even better.

It's when devs really push the hardware / explicitly NEED that additional eSRAM bandwidth for their games to run properly when things get more interesting ...

70mph speed limit doesn't bother you when you're driving a truck that tops out at 65mph anyway ... which isn't to say that driving a truck can't still be a lot fun ;)
 
Yes, and that question was explicitly about bottlenecks and eSRAM, seems pretty clear what was being asked. Let's look at what the article says "I asked him if Capy had noticed any performance bottlenecks while working on the Xbox One. Specifically Microsoft’s use of ESRAM."

Yeah, and it's pretty clear that he answered their simple 2D game would never encounter any such bottlenecks if they exist.
 
The bottleneck is the bandwidth related to DDR3. If eSRAM is too small then that means you have to deal with the bandwidth to off chip RAM and exposing a bottleneck on that end.
 
Developers are starting to use the eSRAM.

One of the developers of Project Cars has commented that they have started with the port of the game for the Xbox One and he has also shown some images. One of the pictures showed that the game was running at 15fps, but he said that's pretty normal at this point of development.

Here is a snippet. (thanks l_Hell_l for sharing)


CL334107 [Common/Renderer] Xbox One - use Title managed resources for deferred contexts - improves significantly multi-threading performance over PC DX11.
CL334142 [Common/Renderer] Xbox One, bump binary mesh format version number
CL334144 [Common/Renderer] Xbox One - add ESRAM support markup to Texture/Target interfaces. enable ESRAM on envmaps,rvm and phase 1 and 3 main render-targets.
CL333745 [Common/Renderer] DX11 - fix for Device permanently locked on VBDecl creation failure. XB1 - add device creation flags for PIX to function in debug builds
CL333774 [Common/Environment] Xbox One - SSE2 paths for Environment Manager colour cube generation (+fix RGB order, fixing FE blueness)
CL333796 [Common/GraphicsEngine] Xbox One - damage renderable fixes
CL333797 [Common/Renderer] Xbox One Deferred Rendering Helper fixes
CL333804 [Common/Common.srcdata] fixup a few shader paths to work correctly with Xbox One.
CL333818 [Common/Appsupport] Xbox One - do damagetick in same place as PC

I've got a few more fixes locally, that need testing on PC - however the Front End is now running without any rendering errors on Xbox One.


The "resources" mentioned at the very beginning could be related to the Tiled resources?
 
Last edited by a moderator:
You mean Project Cars developers. All others with games close to launch do this already of course.
He means all resources, not only tiled ones (which they probably don't use at this stage).
I mention those developers in particular because there is evidence they are using it, hence I decided to share.

Reading posts from you and others I reached the conclusion that unlike the EDRAM on the Xbox 360, Xbox One's eSRAM is not mandatory to use at all.

I think 3dilettante, you, sebbbi, ERP, and even Shifty, etc defined it as a scratchpad memory, which means -among other things- that it is an independent memory which doesn't need the DDR3.

What you say about them not using Tiled resources "at this stage" is interesting because it implies they might use them later on during development. I hope it becomes common practice. But I could be guessing wrong and that's not what you meant.
 
You mean Project Cars developers. All others with games close to launch do this already of course.
He means all resources, not only tiled ones (which they probably don't use at this stage).

Correct. The 68GB/sec total bandwidth of the main ram, is also used for the CPU, which uses about 30GB/sec.
Rendering modern graphics with only 38GB/sec bandwidth.. Imagine that. They would be advertising forza 5 as a graphical benchmark because of it running at 720P/60fps.
Games with complex ingame shaders and lighting would not be able to hit that.
So yes, every current game is using the eSRAM
 
Correct. The 68GB/sec total bandwidth of the main ram, is also used for the CPU, which uses about 30GB/sec.
Rendering modern graphics with only 38GB/sec bandwidth.. Imagine that. They would be advertising forza 5 as a graphical benchmark because of it running at 720P/60fps.
Games with complex ingame shaders and lighting would not be able to hit that.
So yes, every current game is using the eSRAM
No, it _can_ use 30GB/s. I would be very surprised if it used even a tenth of that on an average frame.
 
Correct. The 68GB/sec total bandwidth of the main ram, is also used for the CPU, which uses about 30GB/sec.
Rendering modern graphics with only 38GB/sec bandwidth.. Imagine that. They would be advertising forza 5 as a graphical benchmark because of it running at 720P/60fps.
Games with complex ingame shaders and lighting would not be able to hit that.
So yes, every current game is using the eSRAM

Eh? The GPU can use all 68 GB/s. Or 50 or 40 or 55 or 63 or... I'd be surprised if the CPU uses anywhere near 30 GB/s the majority of the time.

Regards,
SB
 
Eh? The GPU can use all 68 GB/s. Or 50 or 40 or 55 or 63 or... I'd be surprised if the CPU uses anywhere near 30 GB/s the majority of the time.

Regards,
SB
I think it will use bandwidth on demand, so to speak.

To me the most interesting thing about the eSRAM, bandwidth aside, is the potential of low latency. I mean that it could easily impact the framerate of games in very positive ways.

From Digital Foundry's interview with the architects of the console:

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

There are a few things we realised like off-loading audio, we had to tackle that, hence the investment in the audio block. We wanted to have a single chip from the start and get everything as close to memory as possible. Both the CPU and GPU - give everything low latency and high bandwidth - that was the key mantra.
The word "Everything" is he key here to me, it means that if some conditions are right -framebuffer within eSRAM capabilities- the framerate could literally fly.
 
No, it _can_ use 30GB/s. I would be very surprised if it used even a tenth of that on an average frame.

Would you also be very surprised if the resulting games didn't have framestalls, low framerates and microstutter quite often and consistently?
 
The word "Everything" is he key here to me, it means that if some conditions are right -framebuffer within eSRAM capabilities- the framerate could literally fly.
At no point has anyone working on XB1 explained what advantages come with low latency. No-one has even quantified what 'low latency' is. Without clarification I think you're being overly optimistic. Certainly right conditions causing framerates to 'fly' seems like wishful thinking. Right conditions and optimal use would see a small percentage increase, given workloads that cannot be decoupled from other high-latency components. I would rate a 20% improvement in framerates due to low latency ESRAM as phenomenally good. Bare in mind that massive latency has been a 'solved' problem for decades via use of cache, so situations where latency is an issue, although present, are not going to be numerous. If that were the case, computer design would have had a paradigm shift as engineers discovered cache solutions were incapable of keeping the functional silicon active for any decent amount of time.
 
Would you also be very surprised if the resulting games didn't have framestalls, low framerates and microstutter quite often and consistently?

I think Bkilian means the CPU won't restrict DDR3 bandwidth by nearly half, because it generally won't need anywhere near 30GB/s.
 
I think Bkilian means the CPU won't restrict DDR3 bandwidth by nearly half, because it generally won't need anywhere near 30GB/s.

I was just stating that if you don't take into account that the CPU needs bandwidth as well, you will find yourself with big performance issues. Luckily, we have the ESRAM to help with that. Thinking that some current, early games might not be using ESRAM at all, should fall into the wishful thinking category.
 
At no point has anyone working on XB1 explained what advantages come with low latency. No-one has even quantified what 'low latency' is. Without clarification I think you're being overly optimistic. Certainly right conditions causing framerates to 'fly' seems like wishful thinking. Right conditions and optimal use would see a small percentage increase, given workloads that cannot be decoupled from other high-latency components. I would rate a 20% improvement in framerates due to low latency ESRAM as phenomenally good. Bare in mind that massive latency has been a 'solved' problem for decades via use of cache, so situations where latency is an issue, although present, are not going to be numerous. If that were the case, computer design would have had a paradigm shift as engineers discovered cache solutions were incapable of keeping the functional silicon active for any decent amount of time.
That's pretty interesting...

You have been saying that the eSRAM is cache, and latency is solved by using a cache, so why the eSRAM couldn't help with that? :smile2:

I read here that the eSRAM is like 0.4% of the system memory, and that is appallingly low and contrasts strikingly with the total amount of memory.

However, both VGLEAKS documents and the hardware architects emphasised low latency as a key design of the console. :smile2:

The documents say clearly that some great benefits of the 32MB eSRAM are related to latency in preference to bandwidth, and that would be smart given the figures we have at hand with the Xbox One. :smile2:

For instance, X360's EDRAM buffer has 256GB/S of bandwidth, which is an immense amount of bandwidth, even if only for a relatively small amount of storage.

We don't know the figures of latency of the Xbox 360, nor Xbox One. But I think the ESRAM was meant for this especially when you consider that the PS4 could go with 1TB/s of bandwidth if they wanted to.

Microsoft took this approach, but decided to go with less bandwidth. Theory? Latency was preferential compared to bandwidth? :smile2:
 
That's pretty interesting...

You have been saying that the eSRAM is cache, and latency is solved by using a cache, so why the eSRAM couldn't help with that? :smile2:

I read here that the eSRAM is like 0.4% of the system memory, and that is appallingly low and contrasts strikingly with the total amount of memory.

However, both VGLEAKS documents and the hardware architects emphasised low latency as a key design of the console. :smile2:

The documents say clearly that some great benefits of the 32MB eSRAM are related to latency in preference to bandwidth, and that would be smart given the figures we have at hand with the Xbox One. :smile2:

For instance, X360's EDRAM buffer has 256GB/S of bandwidth, which is an immense amount of bandwidth, even if only for a relatively small amount of storage.

We don't know the figures of latency of the Xbox 360, nor Xbox One. But I think the ESRAM was meant for this especially when you consider that the PS4 could go with 1TB/s of bandwidth if they wanted to.

Microsoft took this approach, but decided to go with less bandwidth. Theory? Latency was preferential compared to bandwidth? :smile2:

I couldn't find anything on GCN, nor the consoles. But there are latency figures mentioned for the HD6000 here.

http://www.sisoftware.co.uk/?d=qa&f=gpu_mem_latency&l=en&a=b

It would seem to me that the purpose of most GPU caches is to help with bandwidth more then latency, as the caches seem to have only ~1/2 the latency of the memory but far more bandwidth. If GCN and both the consoles have comparable latency, then would be 'low latency' for the eSRAM?. the same latency as the caches? less? more?.
 
check out the wording Boyd Multerer uses:
xbox_sram_cache2.jpg


Regarding cache latency.

" Having the right data in the right caches at all the right time makes all the difference in the world [for this architecture]"
 
I was just stating that if you don't take into account that the CPU needs bandwidth as well, you will find yourself with big performance issues. Luckily, we have the ESRAM to help with that. Thinking that some current, early games might not be using ESRAM at all, should fall into the wishful thinking category.
There is almost nothing the CPU would be doing that would require any sustained use of 30GB/s bandwidth. It's not like the CPU is generating giant fractals or something. These CPUs have relatively large caches.
Behaviours that would result in large bandwidth use, like a recursive read-modify-write on a very large and changing dataset is really the domain of the GPU. Not even the AI or Physics loop would be that much of a drain on bandwidth, until you get to many many thousands of objects being updated, and even then you could optimize that by utilizing the caches and loading objects that could affect each other in groups.
 
I couldn't find anything on GCN, nor the consoles. But there are latency figures mentioned for the HD6000 here.

http://www.sisoftware.co.uk/?d=qa&f=gpu_mem_latency&l=en&a=b

It would seem to me that the purpose of most GPU caches is to help with bandwidth more then latency, as the caches seem to have only ~1/2 the latency of the memory but far more bandwidth. If GCN and both the consoles have comparable latency, then would be 'low latency' for the eSRAM?. the same latency as the caches? less? more?.
I have been reading that article and I learnt some new things.

Fellow forumers have been trying to find out the differences between AMD's GPUs on the PC and their console counterparts.

And according to this article the thing is that the Xbox One differs from the GCN architecture. Whether the differences imply good or bad news, you can find them here:

<H3>Where are the differences?
Assuming that this information is accurate, the major difference between Durango and a standard GCN is in the cache structure. Modern Radeons have a 16K L1 cache that’s four-way set associative and a shared L2 cache that’s 16-way associative. Durango reportedly has a 64-way associative L1 cache (still at 16K) and an 8-way associative L2.

Here’s why that’s significant. A CPU/GPU cache has two goals: First, it needs to provide the data the CPU is looking for as quickly as possible. Second, it needs to be accurate. Increasing the set associativity of a cache increases the chance that the processor will find the data it is looking for — but it also increases search time.

The other major difference between GCN and Durango is the amount of L2 cache per SC/CU. The Radeon 7970 has 32 Compute Units and 768K of L2 cache total split into six 128K blocks. Durango has 12 Compute Units and 512K of L2 cache, broken into four 128K blocks. Proportionally, there’s a great deal more L2 cache serving each CU with Durango.
</H3>

http://www.extremetech.com/gaming/147577-xbox-720-gpu-detailed-merely-a-last-gen-radeon
 
Status
Not open for further replies.
Back
Top