Predict: Next gen console tech (9th iteration and 10th iteration edition) [2014 - 2017]

Status
Not open for further replies.
function said:
X1 seems to be doing remarkably well for a system with only half the ROPs. Perhaps the leaked docs were telling the truth, and low latency does help with ROP efficiency (so it's merely a disadvantage instead of a massacre)?
Click to expand...
GCN has full fill rate when writing 64 bit render targets. Modern console games bit pack two 32 bit render targets to one 64 bit render target effectively doubling the fill rate (compared to most GPUs).

8 bytes/pixel (64 bpp) * 16 pixels/clock * 853 MHz = 109 GB/s.

Now this is just the ROP color writes. If you use depth buffering or sample any textures, you obviously need even more bandwidth to fully utilize 16 ROPs.

PS4 memory bandwith is 176 GB/s. Subtract the CPU (up to 20 GB/s) and convert theoretical max to actual achievable bandwidth and you see that 16 ROPs are enough. More than 16 ROPs give proper benefits only when you are not bandwidth bound. All 64 bpp modes are bandwidth bound on GCN (as GCN has full speed 64 bpp ROP output). This means that HDR output (4x 16 bit float, such as lighting, post processing, etc) and/or g-buffer rendering (bit packed to 64 bpp RTs) do not get any gains from extra ROPs. More than 16 ROPs gives you benefits when you are rendering to 32 bpp (R8G8B8A8, R11G11B10F, etc) target or when you are rendering depth only (such as shadow maps).

Also you can use compute shaders to completely avoid the ROP bottlenecks. Most games already do this for post processing. Also traditionally high bandwidth rasterizer jobs such as particle rendering can be nowadays done with compute shaders. See here: http://amd-dev.wpengine.netdna-cdn....dering-using-DirectCompute-Gareth-Thomas.ppsx. This technique requires zero memory bandwidth for backbuffer operations or blending, because it renders the particles in tiles using LDS (64 MB local memory inside CU) to hold the backbuffer tile for blending. The final output is written to memory (once) using raw memory writes instead of ROPs.

Having more ROPs is of course nice, but you can avoid the performance hit in most cases... Except in shadow map rendering. 16 ROPs sucks for shadow map rendering :(
 
More than 16 ROPs gives you benefits when you are rendering to 32 bpp (R8G8B8A8, R11G11B10F, etc) target or when you are rendering depth only (such as shadow maps).

...

Having more ROPs is of course nice, but you can avoid the performance hit in most cases... Except in shadow map rendering. 16 ROPs sucks for shadow map rendering :(
Click to expand...
Guess one could say that PS4 is...

...Shady.:cool:

Yeaaah...
 
Okay then, my mistake.
Yes, without ESRAM, 720P games on Xbox One would be the exception... with 720P being the upper limit.

My statement: MS can easily change memory setup for the next Xbox, be it a full generation upgrade or a PS4 Neo type of deal.
 
Egmon83 said:
My statement: MS can easily change memory setup for the next Xbox, be it a full generation upgrade or a PS4 Neo type of deal.
Click to expand...
Easily, based on what technical expertise and/or insider know-how?

I doubt anything really comes all that "easily" at this level, especially when there's a hundred+ titles in the back catalogue (or so I assume; I don't actually know how many xbone games there are by now... :p), and you are required to maintain performance and compatibility with all of them.
 
"easily" compared to running PS2 on PS3, Xbox 1 on Xbox 360, Xbox 360 on Xbox 1 and PS3 emulation on PS4.

Xbox One games are not developed on Xbox One console, or even dev kits. Xbox One games are made on a PC; which does not have any ESRAM. Let that sink in for a minute before we proceed, and yes, dev kits are of course used later in development to fine tune and debug games compiled for the Xbox One hardware.
The game can still be compiled for other hardware, or even other platforms, in the case of multiplatform engines.

Of course, the Xbox 2.x could have problems running the recompiled games; bugs can creep up or the compiler can have errors, but in general; it will be easily achievable as the next xbox will have an enormous performance advantage.

There are only a handful of Xbox Exclusive games, so even in the worst case scenario that ESRAM indeed was the secret ingredient (it was not, looking at every single multiplatform title), MS would only have to remaster a handful of titles, every single other game has a PC version which they could use. So again; ms could easily change architecture, even if it means having to completely redevelop 3 titles.
 
Egmon83 said:
"easily" compared to running PS2 on PS3, Xbox 1 on Xbox 360, Xbox 360 on Xbox 1 and PS3 emulation on PS4.
Click to expand...
Again, based on what technical expertise?

The xbone ESRAM is not just a checkbox in the SDK, programmers use it explicitly. You can't just skip it by unchecking a box; remove the ESRAM and it completely breaks pretty much all existing software (except perhaps some ported indie titles where the universal middleware didn't use it at all for whatever reason.)
 
His poorly worded argument is the PC version of the games can run on XBOneTwo, mitigating any need for working around ESRAM. Platform exclusives written around ESRAM would need a remaster.
 
That's a bogus argument tho, because it would only work for new software. It would leave the entire back catalogue in the lurch, and fixing that is not just unchecking a box and a recompile, so categorically a "not-easy" change.
 
That would work both ways:

Based on what technical expertise do you guys think that a large number of games heavily took advantage of the ESRAM through custom code?

MS was talking about unified platforms before the Xbox One released. Based on common sense, I would assume that they made sure that software could easily be ported or made forward compatible. But on the other hand, MS made a lot of dumb, shortsighted decisions; TV, HDMI IN, Kinect, and so on. You could be very right about ESRAM being one of them
 
Egmon83 said:
That would work both ways:

Based on what technical expertise do you guys think that a large number of games heavily took advantage of the ESRAM through custom code?
Click to expand...
If you paid attention to the discussion, the benefits of ESRAM have already been questioned and the proposition is that GDDR5 might well suffice. However, your question is misguided. Devs have written custom ESRAM code because they have to as there's no way to get XB1 working as well as it does without it! Every game out there running on XB1 is accessing the ESRAM through ESRAM specific code (whether via library or low-level access, we don't know).
MS was talking about unified platforms before the Xbox One released. Based on common sense, I would assume that they made sure that software could easily be ported or made forward compatible. But on the other hand, MS made a lot of dumb, shortsighted decisions; TV, HDMI IN, Kinect, and so on. You could be very right about ESRAM being one of them
Click to expand...
The choice of ESRAM was independent of concerns for portability. It was a question of performance and how to get decent bandwidth and decent RAM amount in an affordable console. In context it was a decent choice - Sony just shocked everyone with 8 GBs where it looked, up until that point, that we'd have an 8GB XB1 versus a 4GB PS4. MS's design of course isn't ideally suited to a mid-gen upgrade, but mid-gen upgrades is something new, and only really happening because PS4 is bascially a PC.

Once again, your ignorance has you insulting various parties (in this case MS's engineers, plus the entire board when you say, "let that sink in for a minute").
 
Shifty Geezer said:
How many games in XB1's back catalogue don't have PC versions?
Click to expand...
I've no idea.

Anyhow, it doesn't matter, because the PC versions of current xbone titles are PC titles, not xbone titles. They're built for windows PCs, use windows APIs, installation methods, largely optimized for mouse and keyboard input, have multitudes of graphics and audio settings not commonly found in console titles and so on.
 
Egmon83 said:
DX12 did not exist when MS was demoing Xbox One:
Also: windows 7 does not have DX12

http://www.slashgear.com/xbox-one-e3-demos-were-played-on-windows-gaming-pcs-15286627/



As for you function: http://www.mobipicker.com/nvidias-gpu-micro-architecture-pascal-trouble-asynchronous-compute-codes/
Click to expand...
No one cares that go forward games can be built without eSRAM! We are talking about backwards compatibility, the title is shipped leveraging a high degree of eSRAM bandwidth using specific XBO DX11/12 calls that specifically move data into and out of eSRAM. So how do you suggest the new upgrade without eSRAM handle XBO backwards compatible games without emulation?
 
Egmon83 said:
Based on what technical expertise do you guys think that a large number of games heavily took advantage of the ESRAM through custom code?
Click to expand...
Check out some GDC and SIGGRAPH presentations (last three years). ESRAM specific custom optimizations are mentioned by several teams. I am confident that every single AAA game is nowadays using ESRAM heavily, and has lots of custom code for it. Without ESRAM the total memory bandwidth of Xbox One is 68 GB/s. Even indie games nowadays are getting so graphically intensive that losing roughly 2/3 of your total memory bandwidth is not a realistic choice.

You need to manually manage your ESRAM usage and allocation policies, move data in/out (using custom move engines) and write/read data to/from the ESRAM using ROPs and compute shaders. XBox One ESRAM is not an automatic cache, it is a fully manual scratchpad memory. Intel's L4 EDRAM cache (in some Broadwell and Skylake models) on the other hand is a fully automated cache. Caches need considerable amount of extra die space for cache tags and coherency hardware. Microsoft (AMD) probably decided that a manual scratchpad is more suitable for a console, because custom code will be written for the console anyway. Intel on the other hand chose to implement fully automated 64MB / 128 MB EDRAM cache in their processor, because PC software is almost never optimized solely for a single architecture.

The UMA memory architectures of modern consoles (Xbox 360, Xbox One, PS4) make it very difficult to emulate games on platforms with a discrete GPU (such as the PC). First party console games can use algorithms where the CPU and GPU are tightly cooperating. This level of (low latency) CPU<->GPU cooperation not possible on a PC with a discrete GPU. In general, no console I have ever worked with has been designed to be fully forward compatible (I have worked with 7 consoles). It is always a trade off to make the next console fully backwards compatible. As long as the console developers are allowed to have low level hardware access, easy 100% forward compatibility will not happen.

The thing is: If Microsoft or Sony didn't allow low level hardware access, but their competitor would allow it, the games would look better and have smoother frame rate on their competitors console. Nobody would like that. Not the customers and not the manufacturers. It's best to let the game developers to use the hardware fully as it results in the best games.
 
Last edited:
Thanks for the insight!
Would you say that, a backwards compatible updated Xbox One built (around GDDR5 or another memory type but) without ESRAM is not possible?
 
Egmon83 said:
As for you function: http://www.mobipicker.com/nvidias-gpu-micro-architecture-pascal-trouble-asynchronous-compute-codes/
Click to expand...

And? It's a completely unsubstantiated rumour which is clearly being reported by someone who doesn't really have much of a clue what async compute is or under what circumstances it can be beneficial.

Async compute is not a requirement for DX12, therefore, gaining little benefit from it is not an indicator of how "DX12 capable" an architecture is.
 
Status
Not open for further replies.

Similar threads

A
Full transcript of John Carmack's QuakeCon 2005 Keynote
3 4 5
Replies
98
Views
34K
nemisis
N
Back
Top