Looking over the VGLeaks diagrams and pages again, I think you might be mistaking a little on the GPU being able to concurrently read and write.

I believe the 'GPU Memory system' portion of the diagram is just to represent the memory allocated for the GPU. I don't think it is meant to suggest that the GPU can read from the DDR3 at 68GB/s and write to the ESRAM at 102GB/s concurrently.

It appears the GPU can either write to this allocated memory at 102GB/s or read from it at 170GB/s but not both concurrently. I believe there is only a single 256-bit memory bus, same as PS4.

If this was the case wouldnt it show a single line with arrows going both ways?

You can only read a 170gb/s as a combination of both memory clients, 102 + 62.

But you can only write back at 102 maximum.
Its all very vague.

All the Move Engine is doing there is moving/copying data between the DDR3 RAM and/or ESRAM. It uses the bandwidth of the DDR3 RAM and/or ESRAM to achieve this; depends on how it is moving/copying the data around.

Yes, it does it in parallel with computation of the GPU but at a slower throughput and at the sacrifice of bandwidth if the memory is being used by the GPU at the time. This doesn't mean or suggest that the GPU can write to the ESRAM and read the DDR3 RAM concurrently.

It can certainly read ESRAM and read DDR3 concurrently.

The 360, can read from GDDR and write concurrently to the EDRAM, thats why its so dam good as a GPU, because it has zero wait states for the memory. Perhaps concurrently is a little of a misnomer, lets just say so dam fast it may as well be concurrent.

It still looks like two separate buss's...

The move engines can move data from EDRAM to EDRAM or DDR to DDR, without messing up the the GPU's own write features to the other.

If this was the case wouldnt it show a single line with arrows going both ways?

No, considering the read and write speeds are different.

Originally Posted by mynd

You can only read a 170gb/s as a combination of both memory clients, 102 + 62.

But you can only write back at 102 maximum.
Its all very vague.

How is it going to concurrently write at 102GB/s if the ESRAM bandwidth is already being used for reading. If the 102GB/s write takes place before or after the 170GB/s read how is that concurrent and different from 1 pool of memory capable of 176GB/s read/write?

Originally Posted by mynd

It can certainly read ESRAM and read DDR3 concurrently.

I didn't say it couldn't read ESRAM and DDR3 concurrently. You were saying it could read and write concurrently; which it can not do. It doesn't need 2 buss's to read or write (one or the other) to the GPU.

The move engines can move data from EDRAM to EDRAM or DDR to DDR, without messing up the the GPU's own write features to the other.

I know, that is why I said if the memory being moved/copied is being used by the GPU.

Nothing that's happened around this DRM reversal is going to impact what happens this gen one little bit. There are some key milestone points in my view which are going to be far more influential.

The first is that it's imperative Sony and MS release on day one with a at LEAST one AAA title, and some good other games. The one who does this best will win this year's Holiday period. Frankly I'd say Sony are ahead in that stake down to the fact that almost all the games they showed at E3 were running on PS4 hardware and not dev kits. I think only two (Forza 5 and Ryse I think it was) were running on One hardware. That's a statement of who is ahead of who in my book.

The second important milestone will be the first price drop. Right now Sony has the drop on MS, but when will MS make a price drop and will Sony be able to respond?

One of the key things that Sony needs to avoid repeating from the release of the PS3 is game delays. Now for this gen it was largely down to the complexity of developing on the PS3, but for the next gen it should be far more even-stevens. It's imperative that the first 12 months drops some good titles and we don't see highly anticipated games slip from quarter to quarter, year-to-year.

How is it going to concurrently write at 102GB/s if the ESRAM bandwidth is already being used for reading.

Each bus can only either read or write.
There would be absolutely zero point of esram if you couldn't read in one bus an output via the other.

If the 102GB/s write takes place before or after the 170GB/s read how is that concurrent and different from 1 pool of memory capable of 176GB/s read/write?

The same way it was different in the xbox360.
Zero wait states, data comes in via one bus, out via the other.

I didn't say it couldn't read ESRAM and DDR3 concurrently. You were saying it could read and write concurrently; which it can not do. It doesn't need 2 buss's to read or write (one or the other) to the GPU.

So how on earth would gpu combine your read results if you don't have two bus's. If you only have the one bus, you are bound by the weakest link (68 gb/s)

I know, that is why I said if the memory being moved/copied is being used by the GPU.

How would address such esram without a second bus, page swapping the 32mb of addressable esram with ddr3?

At the end of the day, esram is doing a slightly more flexible version of what was in the 360. And that was a two bus system. The only difference is, 360
second bus was only addressable by the GPU.

Im pretty sure the move engines are there to help page the frame buffer back to ddr3.

Even this clearly shows a separate bus between GPU->Esram and GPU->Northebridge

The same way it was different in the xbox360.
Zero wait states, data comes in via one bus, out via the other.

So now there are two buss's between the ESRAM and the GPU not just one bus between the GPUESRAM and another between the GPUDDR3? How else is the ESRAM going to achieve 102GB/s read and write concurrently(204GB/s bandwidth).

The only way you can get 102GB/s write with 170GB/s read concurrently is if there are two buss's between the ESRAM and GPU. Edit: Actually I take this part back. Even with two buss's the ESRAM is not capable of 204GB/s bandwidth (102GB/s write and 102GB/s read at the same time).

If there was a bus between the GPUESRAM and the GPUDDR3 then you would have 68GB/s read and 102GB/s write, not 170GB/s read and 102GB/s write.

Originally Posted by mynd

So how on earth would gpu combine your read results if you don't have two bus's. If you only have the one bus, you are bound by the weakest link (68 gb/s)

The memory bus is capable of handling at least 170GB/s bandwidth. There is no reason why the GPU can not read the 32MB of ESRAM at 102GB/s and whatever portion of DDR3 is allocated to graphics at 68GB/s concurrently on a single bus that is capable of handling the bandwidth of the two pools of memory.

Originally Posted by mynd

How would address such esram without a second bus, page swapping the 32mb of addressable esram with ddr3?

The move engine has a bus of its own but only with a bandwidth of 25.6GB/s and it is only used for moving/copying data within the two pools of memory. It only has one path so it has to choose if it is going to move the data between DDR3->DDR3 or DDR3->ESRAM or ESRAM->ESRAM or ESRAM->DDR3.

Originally Posted by mynd

Even this clearly shows a separate bus between GPU->Esram and GPU->Northebridge

It also doesn't show a second bus between the GPU->DDR3. The other diagram also had a bus to the NB but only at 30GB/s bandwidth. I believe the PS4 also has the same 30GB/s bus.

So now there are two buss's between the ESRAM and the GPU not just one bus between the GPUESRAM and another between the GPUDDR3? How else is the ESRAM going to achieve 102GB/s read and write concurrently(204GB/s bandwidth).

No thats not what I said.
I said one bus for ESRAM, one for DDR3.

The only way you can get 102GB/s write with 170GB/s read concurrently is if there are two buss's between the ESRAM and GPU. Edit: Actually I take this part back. Even with two buss's the ESRAM is not capable of 204GB/s bandwidth (102GB/s write and 102GB/s read at the same time).

Whos said anything about concurent read and write back to the Esram?
Of course you cant do that, a bus is either reading or writing.

You can concurrently read form DDR3, and write to the ESRAM.

This is the exact same system they use on the 360.

If there was a bus between the GPUESRAM and the GPUDDR3 then you would have 68GB/s read and 102GB/s write, not 170GB/s read and 102GB/s write.

You can whatever combination you like:
read/read=170 gbs in
read/write=68 gb/s in 102gb/s out. (practically that 68 gb/s because that as fast as DDR3 can go except in framebuffer cases)
write/read=102gb/s in / 68gb/s out (practically that 68 gb/s because that as fast as DDR3 can go -except in framebuffer cases)

Look they even blimmin state it when moving data from ESRAM->DDR3

Although ESRAM has 102.4 GB/s of bandwidth available, in a transfer case, the DRAM bandwidth limits the speed of the transfer.

I dont know why you keep arguing otherwise, its there in black and white.

The whole thing is ideally setup to read/write, just like the 360 with zero wait states.

The memory bus is capable of handling at least 170GB/s bandwidth.

Not one part of this system is desgined to handle 170gb/s that not at all true.

There is no reason why the GPU can not read the 32MB of ESRAM at 102GB/s and whatever portion of DDR3 is allocated to graphics at 68GB/s concurrently on a single bus that is capable of handling the bandwidth of the two pools of memory.

You ever heard of ram timings? Wave cycles?
Of course you cant just bung different spec ram together and ask it all to just "read from the bus".

The move engine has a bus of its own but only with a bandwidth of 25.6GB/s and it is only used for moving/copying data within the two pools of memory. It only has one path so it has to choose if it is going to move the data between DDR3->DDR3 or DDR3->ESRAM or ESRAM->ESRAM or ESRAM->DDR3.

Have you even read these documents?
The only time DRAM->ESRAM makes any sense is if the ESRAM is used as a framebuffer with multiple render targets, or multiple buffers, such as the obligatory depth and stencil buffers.
i.e. 1 source in multiple writes out.

It also doesn't show a second bus between the GPU->DDR3. The other diagram also had a bus to the NB but only at 30GB/s bandwidth. I believe the PS4 also has the same 30GB/s bus.

Wait, for a second I thought you were from 2006, waiting in line to buy a PS3. My bad.

Originally Posted by SchaffinOSX

I like how the author is looking beyond the concrete in a way many people haven't, quite yet. When comparing both consoles, the Xbox One and PlayStation 4 are essentially on equal playing field. Aside from differences in the type of RAM used, both machines are fairly on par with one another with neither showing a clear advantage (although the RAM difference does arguably give the PS4 a long-term advantage in terms of graphical capabilities).

what? even if talking about just hardware, that's not the whole story, at all.

Originally Posted by mynd

Way too early to say anything about these system other than launch price, until the game software matures a bit, its hard to derive anything about the systems, their features or the respective power of each system.

Bull$#@!.

That argument is as thin as the paper the theoretical specs they are written on.
I need to see them running side by side before I decide one has an advantage over the other.

It's not going to be a huge difference in the beginning. Most games are probably not even using much RAM and are mostly multiplats.

Originally Posted by mynd

The issue is, even on the specs we think we know, the GPU on the One is far more efficient than the PS4.

People tend to forget that, yes the PS4 is essentially a similar setup to the Xbox 360 Unified memory system, except for some very important mitigating factors, and that that the 360 has a huge buffer that the PS4 does not have.
It will be interesting to see what happens, but the basic rule of thumb here, is for every thing you put on the screen on the PS4, you use double the bandwidth vs the 360 (or even the paper specs of the Xbox One for that matter),(once to read it, once to write it.

I thought this might be relevant to this thread. It's 4 IGN editors answering a viewer who asks "If you could only buy one system which would it be?" I thought Altano's point about 9 minutes in particularly interesting.

I apologize, it was late and I misunderstood your post as saying it could read at 170GB/s and write at 102GB/s concurrently.

I can see what you are saying but why doesn't either article discuss or at least mention that the GPU can read from the DDR3 memory and write to the ESRAM memory concurrently? It seems that would be something important to go over when discussing the capabilities of the GPU and memory.

We have an example in one of the articles of only the ESRAM being used by the GPU but not one of the ESRAM and DDR3 RAM being used for concurrent read and write.

If the diagram alone is meant to show this, it does a poor job at best. The appearance of the diagram suggests it is nothing more than to show the max bandwidth between connected components and there are two lines for the GPU because the read and write speeds are different.

The only mention I see of another bus or concurrent read/write from the GPU to the memory is for the move engines to the two pools of memory.

The data move engines, which is part of the GPU, has its own bus to the two pools of memory so it can read/write to the two pools of memory while they are being used for read/write by the GPU (so technically a pool of memory can read and write at the same time) and/or during computation. However, this isn't the same as the ESRAM being used for write at 102GB/s and the DDR3 RAM being used for read at 68GB/s to the GPU concurrently.

Why is it exactly the same to the layman? What gives it that definition?

MS are the king of software, they already have the API running to the point where you could simply "port" a DX game from PC across to the One. However, SDK's also gives you fine granular control over specific features that devs can choose to ignore, or get hip deep in. RUn with the norm, and the system is probably not going to give you amazing results. Unlike the PS4. Its staightforward enough to simply start poritng and get blistering results straight away.

And that all depends on the "true efficiencies" that developers may or may not work at for the Xbox One...is it not? That's what we learned with the PS3.

Absolutely, although the PS3 was really hampered by a bottle neck in the GPU, which was a straightforward chip with GDDR and little else...like something else they just made. Although 170 gb/s is not going to bottle neck anytime soon.

Look MS does what they did last gen, they have looked at where the bottle necks are and alleviated the hell out it.

Originally Posted by Ryunosuke

I apologize, it was late and I misunderstood your post as saying it could read at 170GB/s and write at 102GB/s concurrently.

I can see what you are saying but why doesn't either article discuss or at least mention that the GPU can read from the DDR3 memory and write to the ESRAM memory concurrently? It seems that would be something important to go over when discussing the capabilities of the GPU and memory.

Because it's probably not truly concurrent, as I said earlier, concurrent is a misnomer.
It can certainly read concurrently (I have no idea why you would do this to be honest except for perhaps post processing with some input required form the ESRAM).
As you have to wait a cycle op befor eyou can actually write you data, writing the data out will be a cycle behind.

You wouldn't be able to Read Data 1->Op in GPU -> Write Data 1. in one cycle.

Thats going to take 3 cycles I imagine.

What you would be able to do is.

Read Data 3->Op in GPU (Data 2)->Write Data 1

One thing MS keeps banging on about is the rather large caches at either end of this pipeline, and I can see why this is required now.

We have an example in one of the articles of only the ESRAM being used by the GPU but not one of the ESRAM and DDR3 RAM being used for concurrent read and write.

Yes you do, the table show reading and writing from ESRAM and DDR, and vica versa.
This is the GPU "moving" data from one location to another.
As they say, because you are limited by the weakest link they result is 68 gb/s
Thats 68 gb/s READ from ESRAM 68gb/s ->Write to the DDR.
If they weren't able to do this concurrently, you'd actually get a transfer speed of 34gb/s being half that of the weakest link.

But because its two separate bus's your getting 68/68 through both.

If the diagram alone is meant to show this, it does a poor job at best. The appearance of the diagram suggests it is nothing more than to show the max bandwidth between connected components and there are two lines for the GPU because the read and write speeds are different.

The only mention I see of another bus or concurrent read/write from the GPU to the memory is for the move engines to the two pools of memory.

Go look at that table regarding the GPU moving memory between GPU and DDR.

The data move engines, which is part of the GPU, has its own bus to the two pools of memory so it can read/write to the two pools of memory while they are being used for read/write by the GPU (so technically a pool of memory can read and write at the same time) and/or during computation. However, this isn't the same as the ESRAM being used for write at 102GB/s and the DDR3 RAM being used for read at 68GB/s to the GPU concurrently.

I don't think the data move engines are part of the GPU, they are neigh on useless as simple movers, except some of them have hardware compression which is useful, and when the GPU is tied up in compute.

Yea no I don't think even 8GB is enough but come on man, no one can argue with having more RAM being useless. After seeing comments by developers, I feel like even 7GB isn't enough. We're talking about 5!

Yea no I don't think even 8GB is enough but come on man, no one can argue with having more RAM being useless. After seeing comments by developers, I feel like even 7GB isn't enough. We're talking about 5!

How on earth do you get the impression 7gb isn't enough?

You do know PC games cant use more than 4gb unless they are on a 64 bit o/s?

If you referring to games like "The witness", Blow is just being lazy, he's putting the into whole game into memory, with no loading what so ever.

If it becomes an issue, they will do what they always do...stream from HDD.

Inconvenient, but I don't think it will translate to issues on screen. Maybe one day when a game is so complex that its about 100x the size of Skyrim we may have issues.

No amount of RAM is enough, they can always make a more expansive game.

You do know PC games cant use more than 4gb unless they are on a 64 bit o/s?

You do know that next-gen games will only work on 64-bit OSs?

If you referring to games like "The witness", Blow is just being lazy, he's putting the into game into memory, with no loading what so ever.

If it becomes an issue, they will do what they always do...stream from HDD.

and we saw how many developers did that last generation, right? it takes more money and effort. remember the indie game that was already using 5GB? They said that they could load high-res textures on it and basically do everything on the RAM.

Inconvenient, but I don't think it will translate to issues on screen. Maybe one day when a game is so complex that its about 100x the size of Skyrim we may have issues.

I think we should wait and see. I thought 512MB was amazing seeing MGS2 with 48MB RAM and that's not exactly what happened.

There will be a lot of upgrades in things like AI/physics/destruction/shadows/smoke/water/AF/AA/Drawdistance/FPS/resolution etc. that we may not see a huge bump in graphics, just more clarity and subtle changes...until maybe much later into the generation when games are using full power.

We're going to see a lot of MMOs and just open-world games a lot more...no amount of RAM is enough imo. Every single GB counts.

No amount of RAM is enough, they can always make a more expansive game.

You do know that next-gen games will only work on 64-bit OSs?

and we saw how many developers did that last generation, right? it takes more money and effort. remember the indie game that was already using 5GB? They said that they could load high-res textures on it and basically do everything on the RAM.

Meh, streaming is a pain, but I suspect most games will be anyway, we are talking about 50gb blur-ray vs 7 gb of ram.

I think we should wait and see. I thought 512MB was amazing seeing MGS2 with 48MB RAM and that's not exactly what happened.

Wise words.

There will be a lot of upgrades in things like AI/physics/destruction/shadows/smoke/water/AF/AA/Drawdistance/FPS/resolution etc. that we may not see a huge bump in graphics, just more clarity and subtle changes...until maybe much later into the generation when games are using full power.

Oh no doubt somebody will complain about the memory at some stage, but its not going to be indie developers.

We're going to see a lot of MMOs and just open-world games a lot more...no amount of RAM is enough imo. Every single GB counts.

MMO's are interesting, really will depend how much is server side, and how much is locally stored.

Meh, streaming is a pain, but I suspect most games will be anyway, we are talking about 50gb blur-ray vs 7 gb of ram.

Of course but having more memory means less need for the Blu-Ray. Then it just depends on how big the game is...they can keep reusing the RAM to keep the flow going. No one is going to fill up the entire 50GB with textures now right?

Not to mention, you're never going to need to keep all the data into RAM at any point.

Wise words.

I'm glad you agree...I was thinking we were going to see extremely large games...I mean, SOCOM had huge maps but really, we just got prettier games and maybe even smaller games.

Oh no doubt somebody will complain about the memory at some stage, but its not going to be indie developers.

Of course not. You can always work around the memory, you gotta do it in this business.

MMO's are interesting, really will depend how much is server side, and how much is locally stored.

Posting Permissions

PlayStation Universe

Copyright 2006-2014 7578768 Canada Inc. All Right Reserved.

Reproduction in whole or in part in any form or medium without express written
permission of Abstract Holdings International Ltd. prohibited.Use of this site is governed
by our Terms of Use and Privacy Policy.