Support NeoGAF

[badb0y]

I think Yoshida jumped on the quote but the implication in my comprehension was one of them is "surprisingly more powerful than we thought" (xbone was the one thought to not be as powerful) ergo, the Xbox one is surprising with its power meaning they will be "consoles pretty much on parity ".... one sticking up a little was the difference on PS4 having a slight edge over xbone but not as much as raw specs have led people to believe

I took that quote totally differently than anyone else.

What we’re seeing with the consoles are actually that they are a little bit more powerful than we thought for a really long time

Remember the rumors of Xbox One and PS4 having HD 7600 series GPUs......I think that's what he is referring to because when they got the earliest devkits the APUs were weak as shit.

ESPECIALLY ONE OF THEM, but I’m not going to tell you which one," Nilsson told VideoGamer.com at Gamescom earlier today.

The GPU that Xbox One uses was pretty much expected to be used in the next gen consoles, something around the level of 7770 which is considered mainstream. It's a decent GPU that gets the job done for casual gamers. The PS4 GPU is much better than expected, the performance sits somewhere between a 7850 and a 7870. The GPUs in this range are considered mid-ranged and are for people who don't have the budget of enthusiast class cards but still want power to play games with some eye candy. No one would have been able to guess this if it was a year a go.

I seriously expected both consoles to have a mainstream level GPU in them.

And that makes me really happy. But in reality, I think we’re going to have both those consoles pretty much on parity – maybe one sticking up a little bit.

This is a third party-developer they won't put any effort into exploiting hardware to it's full potential when the game is mult-platform. I took this as:

PS4 - High settings
Xbox One - Medium settings

Since this would allow one version to look slightly better but not the extent that people would complain.

 

[Dictator93]

"1024 bits wide"


hrmmmm

 

[link1201]

I don't understand much about tech, but I like this line.

Yeah...works for me. I'm getting more hyped for next Gen on a daily basis.

 

[Lynn616]

It's amazing how some of you can truly think you know more (or better) than the people working (and engineering) for these companies. Let alone websites like ExtremeTech, that specialize in knowing about computer tech in extreme detail. The "they are absolutely wrong" statements made by some here really amuse me.

I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about.

Spoiler

H.P. Lovecraft

 

[Klocker]

Good info thanks all.... ^^^^

So assuming the hot chips analysis is incorrect and it is not a "cache" in pure terms, then how will the esram be addressed? by programming for it specifically? Is this any different than how edram was used in 360?


I guess I'm wondering why use the esram and not be a cache if there is not a distinct advantage? Or is there an advantage that just requires more programming and could Ms tools be designed to streamline that process for devs?

 

[LukasTaves]

The question is not if it is capable of GPGPU but if its memory subsystem supports certain use cases as well as the PS4's more capable setup. It's a bit weird to read that the article stresses the bandwidth figures between the memory pools and clients in particular, since those have been known for quite some time now. The very fact that they are all "inferior" compared to the PS4's setup actually was taken as another disadvantage for the XB1. So I am a bit puzzled why the article interprets those figures as a surprising and good thing.

Furthermore, the article is just plain wrong in some places. For instance, the fact that the ESRAM is physically implemented as four blocks of 8MB doesn't matter at all. Neither does it affect performance nor does it prevent a unified address space for the ESRAM. And, as others have stated, the ESRAM is not a cache. It's first and foremost there to hold pixelbuffers. (It doesn't have to be used in that way, but it wouldn't make any sense to not use it for that.) Apart from that, it can be used for other use cases. In combination with the DMEs, textures can be prefetched and stored there. Or it can be use as a generic scratchpad for GPGPU.

However, all of this is no secret sauce. It is still "just" memory. It is there to provide additional bandwidth that the DDR3 in itself just can't provide. Its downside in comparison to the PS4 is that this pool is just 32MB big whereas the PS4 has more bandwidth on the entire memory pool. 32MB are enough to store the most important pixelbuffers. Nevertheless, you can still saturate the pool easily if you are using deferred (two-pass) rendering which uses multiple "auxiliary" buffers for storing information gathered in the first pass. KZ:SF, for instance, uses 39MB at 1080p for pixelbuffers alone.

You are putting the esram under a much more limiting light than it actually is. The system is flexible enough so the limited space won't be much of an issue.

They don't need to fill any buffer entirely on the esram, for instance. With hardware support for virtual addressing even in tiled space, they could render the opaque pixels on the DDR3 (and since they are all opaque bandwidth wouldn't be an issue), and at the same time render the alpha blended pixels on esram, with plenty of bandwidth to go crazy (And if Ms is to be believed, one scenario where the extra bandwidth is achieved on esram is when rendering alpha blended pixels with high precision formats).

They don't need to store non needed pixels on esram too. PRT and virtual texture also allows the gpu to copy only the texels that are actually going to make into the final image to the esram, and even those can also be scattered across both pools of ram. On the worst case scenario you need a texel for each pixel of the screen, and at a 1080p that's not more than a few megs. And the same principle also applies for buffers that are generated on the fly like shadowmaps and even 3D textures like a voxel representation of the scene...

And also, the esram is usable as a low latency, high speed pool of data that the gpu can use for gpgpu and compute...

And I still don't believe it's there only to provide bandwidth. If that was the main concern Ms could have gone with other solutions. Being low latency seems integral to their design, they even so constantly talk about super computer architecture (which are indeed moving towards lots on inside chip memory to increase performance, specially on heterogeneous architectures).

 

[badb0y]

It's amazing how some of you can truly think you know more (or better) than the people working (and engineering) for these companies. Let alone websites like ExtremeTech, that specialize in knowing about computer tech in extreme detail. The "they are absolutely wrong" statements made by some here really amuse me.

They are guessing right now just like VGLeaks and other sites talking about the technical details. I can bring up another article that will refute what the article in the OP presents but that wouldn't change the fact that both articles are just interpretations.

 

[astraycat]

You are putting the esram under a much more limiting light than it actually is. The system is flexible enough so the limited space won't be an issue.

They don't need to fill any buffer entirely on the esram, for instance. With hardware support for virtual addressing even in tiled space, they could render the opaque pixels on the DDR3 (and since they are all opaque bandwidth wouldn't be an issue), and at the same time render the alpha blended pixels on esram, with plenty of bandwidth to go crazy (And if Ms is to be believed, one scenario where the extra bandwidth is achieved on esram is when rendering alpha blended pixels with high precision formats).

They don't need to store non needed pixels on esram too. PRT and virtual texture also allows the gpu to copy only the texels that are actually going to make into the final image to the esram, and even those can also be scattered across both pools of ram. On the worst case scenario you need a texel for each pixel of the screen, and at a 1080p that's not more than a few megs. And the same principle also applies for buffers that are generated on the fly like shadowmaps and even 3D textures like a voxel representation of the scene...

And also, the esram is usable as a low latency, high speed pool of data that the gpu can use for gpgpu and compute...

And I still don't believe it's there only to provide bandwidth. If that was the main concern Ms could have gone with other solutions. Being low latency seems integral to their design, they even so constantly talk about super computer architecture (which are indeed moving towards lots on inside chip memory to increase performance, specially on heterogeneous architectures).

This isn't really how rendering works. You don't get to pick and choose which pixels go where in memory -- you allocate enough space for the entire render target and you bind that.

Sure, you may be able to use PRT on the render target and have some tiles in ESRAM and some tiles in main memory, but then you'll need to know before you render which tiles to put in ESRAM and which tiles to put into main memory. It sounds better to just put your entire render target into ESRAM, since this relieves bandwidth pressure to main memory for other things like texturing.

ESRAM is also unlikely to have much lower latency compared to main memory. I doubt it sits in front of the L1/L2 caches, which means you'll have to go through their latency in the first place to even make it to ESRAM.

 

[phosphor112]

It was always capable of GPGPU. The article actually doesn't present or discuss any information that we hadn't months ago. The HotChips talk actually "just" confirmed pretty much everything that we knew from the leaked Durango documents (after taking the change in GPU clock from 800mhz to 853mhz into account) which is nice.

The question is not if it is capable of GPGPU but if its memory subsystem supports certain use cases as well as the PS4's more capable setup. It's a bit weird to read that the article stresses the bandwidth figures between the memory pools and clients in particular, since those have been known for quite some time now. The very fact that they are all "inferior" compared to the PS4's setup actually was taken as another disadvantage for the XB1. So I am a bit puzzled why the article interprets those figures as a surprising and good thing.

Furthermore, the article is just plain wrong in some places. For instance, the fact that the ESRAM is physically implemented as four blocks of 8MB doesn't matter at all. Neither does it affect performance nor does it prevent a unified address space for the ESRAM. And, as others have stated, the ESRAM is not a cache. It's first and foremost there to hold pixelbuffers. (It doesn't have to be used in that way, but it wouldn't make any sense to not use it for that.) Apart from that, it can be used for other use cases. In combination with the DMEs, textures can be prefetched and stored there. Or it can be use as a generic scratchpad for GPGPU.

However, all of this is no secret sauce. It is still "just" memory. It is there to provide additional bandwidth that the DDR3 in itself just can't provide. Its downside in comparison to the PS4 is that this pool is just 32MB big whereas the PS4 has more bandwidth on the entire memory pool. 32MB are enough to store the most important pixelbuffers. Nevertheless, you can still saturate the pool easily if you are using deferred (two-pass) rendering which uses multiple "auxiliary" buffers for storing information gathered in the first pass. KZ:SF, for instance, uses 39MB at 1080p for pixelbuffers alone.

As already stated in many other threads, the actual differences in GPGPU are not "radical" in general, but there are some: for instance, the PS4 supports selective control of its GPU cache lines to distinguish between cached data that is shared with the CPU or not. The XB1 seems to have to flush the entire GPU cache when it wants to synchronize. In addition, the PS4 has more scheduling and buffering logic for GPU instructions to saturate its ALUs more efficiently. Independent of what "hUMA" is supposed to be comprised of, when we discuss the memory subsystems and how they support GPGPU, there are some differences.

Again, this does not mean that the XB1 cannot do GPGPU. I am not even interested in "console war" comparisons, just in understanding the tech better. And the conclusions drawn by the article are either old news or are incorrect.

Great rundown of things. I still want to know how they got that 204 number.. lol. It just boggles my mind.

 

[oVerde]

Whatever numbers makes you sleep better.

 

[BruiserBear]

I validated the price in my mind when i pre-ordered on June 10th.

It would just make no sense for MS to put out a product so inferior that the third party games are way worse on theirs. That would end in them getting crushed.

The console may, in fact, be weaker but they would never let it be so much that they lose their existing audience. They need to keep those users while expanding the base with Kinect, TV, etc.

It also makes no sense to force a 24 our check in on your customers, and demand they have a Kinect plugged in to even use the console, and to force the Kinect into every single box even though a lot of people will never use it, and all of that resulted in the console costing $100 more than the competition.

You would think they'd never do any of that, but yet they did. So yeah, they did design a console that is notably less powerful than a PS4. That doesn't mean the XB1 is weak or not going to produce impressive games. It will, but there are going to be notable differences, especially between multiplatform games where you have a directly comparable example.

 

[wildfire]

What is hUMA and why is it so important all of a sudden?

This example isn't huma but it gets across the significance better.

You know how in PCs GPUs can't share memory in crossfire/sli? You also know if GPUs could do that so much memory would be available playing games with 5+ monitors would be stable?

Well huma is sort of like finding a way for GPUs to share memory.

In this case though the memory sharing is between the CPU and GPU which opens up so many more options considering how vastly different the components are.

 

[SenjutsuSage]

If this chip is so good at that one aspect vs intel chips, why doesn't AMD implement this solution onto all of it's upcoming chips?

Oh, come on, I think this has to be the most overused thing to say when a console has a specific or unique implementation of anything. Also, hUMA will be mplemented on all future AMD chips, as far as I'm aware. And literally not everything can make it into a PC design for any number of reasons, no matter how useful it may be.

Also, I don't know if what they are doing is 'hUMA' or whatever, but they certainly do seem to have a number of check boxes ticked off. Whatever the case, people were seriously deluding themselves if they really believed that Microsoft and AMD's engineers hadn't done as much as possible to ensure that the Xbox One is a really strong and capable machine. It's not enough, it seems, that the PS4 has more raw horsepower that is pretty well documented, people have to also try their best to downplay the design of the Xbox One. The only areas in which this system seems lacking is DDR3 instead of GDDR5 and a weaker GPU.

Like that Extremetech article implies, the Xbox One seems to have all the very same things that resemble what the Garlic and Onion buses achieve for the PS4. And if people are wondering about Onion+, who knows, maybe that's what that thin black line trailing from the CPU all the way down to the ESRAM is all about. Maybe it's used to somehow gain direct access to the ESRAM. Or perhaps it's implying that the CPU in Xbox One, like Intel's Haswell chips, can somehow use the Xbox One's 32MB of ESRAM like an extra large cache, or if not a cache, then just as a developer managed buffer to help with CPU operations? In 8MB partitions the latency should be pretty decent on the ESRAM chips, so maybe that's an interesting enhancement for the Xbox One CPU of sorts? I don't know, Microsoft hasn't really explained this stuff in detail yet.

 

[AdlaiSeven]

This is a third party-developer they won't put any effort into exploiting hardware to it's full potential when the game is mult-platform. I took this as:

PS4 - High settings
Xbox One - Medium settings

Since this would allow one version to look slightly better but not the extent that people would complain.

Personally I think we will end up like this for next gen:

PS4 - Medium settings
XB One- Medium settings
PC - High settings

I think if your hope is the PS4 will be 40% more powerful outside of paper specs, you will be disappointed.

 

[phosphor112]

You probably mean 64 bytes.

I don't know what cache lines are, but the jaguar has 64kb of L1 per core. 32kb data, 32kb of instruction set. Is that cache broken down even more into those lines?

Good info thanks all.... ^^^^

So assuming the hot chips analysis is incorrect and it is not a "cache" in pure terms, then how will the esram be addressed? by programming for it specifically? Is this any different than how edram was used in 360?

I guess I'm wondering why use the esram and not be a cache if there is not a distinct advantage? Or is there an advantage that just requires more programming and could Ms tools be designed to streamline that process for devs?

Yes, eSRAM (and eDRAM) need to be programmed for specifically. Just like regular RAM. It's more difficult to juggle data between main ram and the eSRAM. It's not impossible though. It certainly is no Cell.

 

[LukasTaves]

scratchpad . http://en.wikipedia.org/wiki/Scratchpad_memory



cache.



Bolded is the important difference.

The Data Move Engines patent (which I'm not sure if it's the same as the xbone has, but does seem too similar to not be) actually describe something like this as one of their tasks...

The dmes, according to the patent, like a DMA can be directly controlled by the cpu writing on their registers a copy operation, for instance. But they can also listen for some sort of flags raised by the running application which might indicate a possible need to copy data and so they have a chance to copy said data in advance, so when the application needs it, it's already there on the desired memory... It's been a few months since i read the patent (And the language patent on top of being english make it quite a difficult read for a non native english speaker like me) but I think they specifically call this operation as in memory caching.

 

[tokkun]

I don't know why people keep using the word 'cache' to describe the eSRAM, its not a cache its a scratchpad.

Scratchpads are sometimes referred to as "software-managed caches", so it's not technically incorrect, though I prefer the term scratchpad as it is less ambiguous.

 

[Manmademan]

I validated the price in my mind when i pre-ordered on June 10th.

It would just make no sense for MS to put out a product so inferior that the third party games are way worse on theirs. That would end in them getting crushed.

The console may, in fact, be weaker but they would never let it be so much that they lose their existing audience. They need to keep those users while
expanding the base with Kinect, TV, etc.

why not? first, power isn't everything. MS is probably aware that only a small segment of their fanbase is really that sensitive, and they we're hoping to make up for that and then some by appealing to casuals with TV integration. The pushback against their media plans turned out to be FAR more than anticipated though.

second, they underestimated Sony. They were all but certain GDDR5 wouldn't be available in densities that would allow 8 gigs by launch. So "xbox has twice the ram" would have been a hell of a talking point. unfortunately Sony got lucky and now is in a better position.

third, this has happened twice already. the ps1 and Saturn launched the same year, and Sonys console blew the doors off of segas in terms of 3D. the gap was obvious and massive. Sega misread the market, built a 2D focused console and had to do a 180, scrap plans and bolt on 3D capabilities to compete at a price 100 dollars more. sound familiar?

the gen immediately afterwards, Nintendo saw fit to launch the GC next to the xbox which was demonstrably stronger, despite being only about a month apart. the ps2 was so well established by then that both consoles were also rans, however.

 

[badb0y]

Personally I think we will end up like this for next gen:

PS4 - Medium settings
XB One- Medium settings
PC - High settings

I think if your hope is the PS4 will be 40% more powerful outside of paper specs, you will be disappointed.

Yea, OK.

They put in stronger hardware for parity, should have gone with the 7750 nad DDR3 memory to save money.

EDIT: You just reminded me of a post I made a few weeks ago.

Holy shit, those idiots over at Digital Foundry have really fucked up this conversation, haven't they?

To preface this post I want to say that although I admire what Digital Foundry tried to do but their methodologies were not only flawed but straight up wrong.

The first thing they did wrong was select the wrong graphics cards to correctly compare the 2 situations.

For the Xbox One they used a HD 7850 over a HD 7790 while for the PS4 they used a 7870 XT over a 7850. This is wrong because using the 7850 for the Xbox One thrusts it into a whole different category of graphics cards that bring many advantages not present in the Xbox One GPU (32 ROPs vs 16 ROPs).

The methodology they used would have been perfect if they grabbed a HD 7790 and clocked it to ~731 Mhz for the Xbox One's GPU and used a a HD 7850 and clocked it to 898 Mhz.

Xbox One = 1.310 Teraflops ------- (HD 7790)Bonaire @ 731 Mhz = .731*2*896 = ~1.310 Teraflops
PS4 = 1.84 Teraflops ------- (HD 7850)Pitcairn @ 898 Mhz = .898*2*1024 = ~1.84 Teraflops

I reckon using these cards at these clocks would really show the GPU difference between the two consoles but alas Digital Foundry went about this some other dumbass way.

To get to the point since I don't have the hardware I mentioned above on hand to conduct the tests myself but I can extrapolate data from graphics cards that are similar to what goes into these consoles. For the Xbox One that would be an HD 7770 because it has a similar amount of GPU power as the GPU used in the Xbox One (1.310 Tflops vs 1.28 Tflops) while for the PS4 I would use the HD 7850 (1.84 Tflops vs 1.76 Tflops) and then compare the results for a realistic look at the performance gap. Oh, by the way the gap between 1.28(HD 7770) and 1.76(HD 7850) is smaller than the gap between 1.31(Xbox One) and 1.84(PS4) so that's already giving a slight break to the Xbox One in this comparison.

For my analysis I am using benchmark numbers from Anandtech.com:
http://anandtech.com/bench/product/777?vs=778
Using the data above I came up with the following chart:

I submit to you that the performance difference between the Xbox One and the PS4 will be much more apparent than what Digital Foundry has hypothesized and that the overall difference in power will not only be tangible but possible even staggering.

 

[jmdajr]

fantastic

 

[LukasTaves]

This isn't really how rendering works. You don't get to pick and choose which pixels go where in memory -- you allocate enough space for the entire render target and you bind that.

That's usually how it works. But the xbone architecture seems to be different.

From the Vgleaks we know that:

- All the gpu sees is 1TB of virtualized address. Those address can be mapped seamlessly on either pool of memory.
- The DMEs have hardware support to tile and untile, pretty much everything that makes sense to be tiled. IIRC, the vgleaks even say that operating on pixels scattered acroos both rams is a possibility.
- The Gpu can read and write at the same time from both memory pools. There's no restriction on which part of the gpu can access each memory. For the gpu each pool is the same, flexibility wise.

Sure, you may be able to use PRT on the render target and have some tiles in ESRAM and some tiles in main memory, but then you'll need to know before you render which tiles to put in ESRAM and which tiles to put into main memory. It sounds better to just put your entire render target into ESRAM, since this relieves bandwidth pressure to main memory for other things like texturing.

That's one possible solution, but not the only one. That's actually the point. The design is flexible enough so you can have many different setups, which means you can find one that gives better performance to your application.

ESRAM is also unlikely to have much lower latency compared to main memory. I doubt it sits in front of the L1/L2 caches, which means you'll have to go through their latency in the first place to even make it to ESRAM.

I don't have actual data, because I never programmed on the xbone, but on b3d, even a sony employee was speculating the esram latency to be on the order of 10's of gpu cycles, while main memory latency tend to be in the order of 100's...

 

[DJ Lushious]

third, this has happened twice already. the ps1 and Saturn launched the same year, and Sonys console blew the doors off of segas in terms of 3D. the gap was obvious and massive. Sega misread the market, built a 2D focused console and had to do a 180, scrap plans and bolt on 3D capabilities to compete at a price 100 dollars more. sound familiar?

No. Comparing the Xbox One and PS4 to the PSX and Saturn is laughable.

 

[ConteZero76]

DDR3-2133 dwarfs DDR3-1600 confirmed.

 

[astraycat]

That's usually how it works. But the xbone architecture seems to be different.

From the Vgleaks we know that:

- All the gpu sees is 1TB of virtualized address. Those address can be mapped seamlessly on either pool of memory.
- The DMEs have hardware support to tile and untile, pretty much everything that makes sense to be tiled. IIRC, the vgleaks even say that operating on pixels scattered acroos both rams is a possibility.
- The Gpu can read and write at the same time from both memory pools. There's no restriction on which part of the gpu can access each memory. For the gpu each pool is the same, flexibility wise.

Virtual addresses are not seamless. They are mapped on top of pages, which at the the minimum are 4KiB in the size on GCN. However, textures (and render targets) have special tiling modes, and my not have a supported mode that actually resolves to 4KiB tiles. The PS4 and desktop GCN cards have texture tiles of 64KiB. Even if DME's can magically untile memory, it's not going to solve the issue that texture pages are likely to be 64KiB in size.

On top of that DMEs aren't going to be able to intercept pixels from the ROPs, which is really what you would need to do to scatter blended pixels. ROPs are going to operate on top of a render target, and render targets are going to follow texturing rules.

That's one possible solution, but not the only one. That's actually the point. The design is flexible enough so you can have many different setups, which means you can find one that gives better performance to your application.

I think you're really overstating the system's flexibility. Virtual memory is flexible sure, but it still has a lot of rules.

I don't have actual data, because I never programmed on the xbone, but on b3d, even a sony employee was speculating the esram latency to be on the order of 10's of gpu cycles, while main memory latency tend to be in the order of 100's...

L1 latency is likely in the 100s of cycles (GDC GCN slides mention that L1 latency is on average 20x that of LDS, which is probably much closer to the 10s of cycles range as it's actually attached to the CU before the caches). I would have guess that the ESRAM was going to have really good latency too until I really looked into the latency of AMD cards. Sony employees are just as just as susceptible to speculation as anyone else. Latency numbers for things like caches aren't exactly bandied out in the SDK notes. You'd actually have to go looking for them to find them.

 

[Sounddeli]

PS4 XBO Difference
Texture reads(gt/s)...........56........41.....36.59%
Vertex throughput(bn). .....1.6........1.7....-5.88%
Output(gp/s)..................25.6.......13.6....88.24%
Ops/cycle......................1152......768....50.00%
TF................................1.84......1.308...40.67%


So what does it all mean?
The Texture reads are the number of textures you can "fetch" in per second from a given source. Its exactly what it means. The PS4 can grab 36% more textures per second.

Vertex throughput - Conversely, because both are tied to there clock speed, the end result is, the XBO has an advantage on just how many things it can display on screen per second (note: I'm not saying how pretty those things are).

Output- This one is a little squishy, while the raw numbers would favor Sony, the real trick here is to try and output only what is required. The more useless information you can "kill" and not output at all, the better.
Couple together the ability to store data in a compressed format, a rather large ROP cache that allows for depth testing pre pixel shader work, and you make significant gains in output. It's really really hard to come up with any sort of meaningful conclusion on this one other than to say they both have more than enough grunt to do 1080p 60fps with well over 10 overdraw easily.

Op/s per cycle.......Now here's the one that you need to get you head around and where the famous "50%" more power tends to get bandied about. A few things you have to understand about a graphics pipeline, and that is that its entirely programmable. The length and complexity of those calculations is entirely up to the programmer running for both vertex and pixel (and others these days).

I wont get to much into but lets put it this way. If dev choose a rather lengthy complex calculation to run on a pixel shader, then this will favor the PS4. If not, then it wont affect either, except for the fact that the XBO is pushing more cycles per second.

The best way to thing of it is like lines of code, this is by no means a correct analogy, but its the best I can come up with....

If the programmer runs code on shader that's less than 768 "instructions", then it favor the XBO due to its higher clock rate.
If the code is larger than 768 "instructions" then it favors the PS4.

Here's the kicker though, because this code is running "per vertex" or "per texal" ie. per model or mesh, then your still tied to your vertex throughput or texture fetch rate.
One of these does allow for the PS4's greater lines of code, by allowing for more texture fetches, but on a vertex by vertex rate? Your still limited to clock speed.

The only conclusion I make from this is, that for most tasks, shadow mapping etc it's pretty much a wash outside of clock rate.
The PS4 allows for more complex code in terms of allowing more textures per model or mesh, and more complex and lengthier code "per model".

The end result will likely be a wash in terms of most assets used. Models, the number of models, "things going on" is identical. The actual texture resolution though, this favors the PS4, whether that be through the number of textures applied to a model, or simply higher res textures.

I cant help but think of the PS4 render pipeline architecture as a snake, whose eaten a rather large meal. He has this rather large belly in the middle of it. While its head and tail are sleek.
The issue being of course, if you use that overhead "space" or not.

Conclusion:Things aren't going to be "faster" you not going to see "more things" on the PS4 graphics. What you may see is higher res textures, or better texture effects possible on the PS4. While I expect the frame rate to be steady and the same on both. My gut feeling is, that extra "bump" in the snake is there for compute calculations.

Now, what Ive left out of all of this, is the extra work that either the CPU or GPU have to do on the PS4. There is no real way of conclusively discussing that as Sony hasn't been terribly forthcoming on and additional hardware specs.
But, as things stand, there's and awe-full lot the PS4 has to deal with outside of simply drawing a polygon, that will need either CPU or GPU resources, and could impact on that extra compute claculations overhead the PS4 has.

 

[Fourth Storm]

Wonder what their version of "Onion" is running at. Looks like their CPU to memory bus is near double Sony's. This is probably essential for Kinect. Can't wait to see how performance compares.

 

[Suikoguy]

Sounddeli, are you taking into account the difference of Shaders and ROPS into your conclusion?

 

[USC-fan]

Was it confirm xbone has dual setup eninge and ps4 doesn't?

 

[Pain]

So Xbox One more efficient than we thought. But its still less powerful than a PS4?

 

[RayMaker]

Wait, what?

I don't know how often we will hear that "bu... but...PS3/Xbox360 this gen.." comment again. As I've already said in several other threads. The PS3/Xbox360 were nearly identical, performance wise, if you look at their best games.
The gap between the PS4 and XBone is much bigger.
And only the CPU is the exact same. That's it.

btw. the "saves money not to do anything witht he PS4 extra power" is bullcrap,
because you don't have to work 20 hours a day, to get a bit more out of the PS4. This is wishful thinking and not how it works.

Damn, I have to find the great post of Amir0x regarding that topic.

Like I have said to you before even though the performance is higher on the PS4, due to both consoles being so similar architecturally the visual difference may be smaller then 360/PS3.

http://www.youtube.com/watch?v=Hvp3UStDJUg

It makes sense that Devs will just tinker around with setting so IQ and fps are the same on both platforms,it will just be like if X1 was on high settings and PS4 is on very high settings.

 

[cripterion]

so you're completely disregarding the fact that PS4 is proven to have better performance by ~40% because of released known specs of both systems, and that X1 is $100 more because of kinect? because fanboys?

Again with the 40% BS. Show me BF4 running 40% better on PS4 compared to the Xbone version and I'll gladly eat some crow.

 

[boredandlazy]

Again with the 40% BS. Show me BF4 running 40% better on PS4 compared to the Xbone version and I'll gladly eat some crow.

You can lead a horse to water, but you can't make it drink.

 

[Manmademan]

No. Comparing the Xbox One and PS4 to the PSX and Saturn is laughable.

put aside the performance comparison for a second, because it's obviously not going to be that large.

but as an example of two competitors releasing consoles in the same year, one weaker than the other because sega misread the market (as Microsoft CLEARLY did, hence the 180) it's absolutely valid.

 

[SenjutsuSage]

So Xbox One more efficient than we thought. But its still less powerful than a PS4?

It's not packing the kind of raw power as a PS4, but it's an incredibly capable and well built console that has a quite a bit of special purpose hardware to help with some of the more common tasks of a GPU. This system sure as hell won't be weak by any stroke of the imagination. On just the hardware alone, it will be quite capable, but then there's all these special purpose processors, 15 of them in total, that will take away or offload work from both the CPU and the GPU, so it's going to be near impossible to tell just how well this thing will perform, but it's certainly carefully thought out enough where you should expect to see some developers achieve some incredible results.

At the end of the day it's not stronger than the PS4, but it doesn't need to be in order to still be a really powerful piece of console hardware.

That said, anyone still somehow believing that the Xbox One is going to hold back the PS4, clearly aren't paying attention or internalizing the importance of the architectural similarities between the two systems. The PS4, just by the very nature of being, should be expected to have a pretty decent advantage on the sole basis that the gpus are so architecturally similar, only the PS4 has more raw horsepower, and the PS4 has a more easy to work with single pool of GDDR5 with all the system's memory bandwidth. Sure, there may be special considerations to take into account regarding the PS4, but those special considerations are likely to all be on its advantage in compute thanks to the extra ALU resources, but if you're talking from a purely graphics performance standpoint, the PS4 will not be held back by the Xbox One, and people really shouldn't be using that excuse. There's no reason the PS4 shouldn't benefit simply from having more basic execution resources on its GPU. If people are dying to see the superior versions of a game, then there's a safe bet you'll see it on the PS4, just don't be disappointed when the Xbox One version doesn't look and perform as bad in comparison to that PS4 version as some people think it should.

 

[RSTEIN]

So Xbox One more efficient than we thought. But its still less powerful than a PS4?

Of course it's less powerful than PS4. But both are not powerful at all.

 

[ElTorro]

They don't need to fill any buffer entirely on the esram, for instance. With hardware support for virtual addressing even in tiled space, they could render the opaque pixels on the DDR3 (and since they are all opaque bandwidth wouldn't be an issue), and at the same time render the alpha blended pixels on esram, with plenty of bandwidth to go crazy (And if Ms is to be believed, one scenario where the extra bandwidth is achieved on esram is when rendering alpha blended pixels with high precision formats).

I don't see how you possibly could dynamically determine the memory location of individual pixels based on their properties. Maybe you have tile-based deferred rendering in mind? That works differently.

 

[pixlexic]

Again with the 40% BS. Show me BF4 running 40% better on PS4 compared to the Xbone version and I'll gladly eat some crow.

Yeah I don't see it happening either.
Not sure why some people want to make such bold claims before actually seeg a comparison is beyond me.

 

[SniperHunter]

Of course it's less powerful than PS4. But both are not powerful at all.

yup. I bought a GPU last year and it packs 3.5 to 4 t flop performance. Both consoles are very weak, let's hope this gen last for 5 years

the 40% isn't bs, its a fact. Deal with it

 

[SenjutsuSage]

Yeah I don't see it happening either.
Not sure why some people want to make such bold claims before actually seeg a comparison is beyond me.

This is what it will ultimately boil down to. We already know what the numbers are for these systems, and they favor the PS4. However, the numbers have been beaten to death, and are now old news. The games being designed for these systems and released will be the new news. Those will tell us the real story in a way that only they can.

yup. I bought a GPU last year and it packs 3.5 to 4 t flop performance. Both consoles are very weak, let's hope this gen last for 5 years

the 40% isn't bs, its a fact. Deal with it xbottles

Not like I care, since I'll have both anyway, but be honest, do you see a 40% difference across the board in PS4 and Xbox One games so far? This is why it's best to wait for the games, but if people are looking for games that look 40% better across the board or 50% better across the board, they may be very disappointed. For example, 30 to 40% of that extra power can just as easily be blown on a much better looking AA solution, or extra environmental reflections at a certain level. I think what people may be looking for is massive differences in the appearance of the graphical assets in the games, or the number of things on screen, but I don't think people are going to see that, but what you're likely to see is PS4 with a superior resolution to the Xbox One version, which may be slightly lower, or if they're the same resolution, the PS4 version will likely have a more stable framerate across the board compared to the Xbox One version. The real big visual difference between PS4 and Xbox One is likely to be in amazing GPGPU stuff years down the road. Even Cerny himself said he expects this stuff to be a big deal 3 or 4 years in. That will be where the PS4 will truly outshine the Xbox One, but I don't think it's going to do so as much in the other ways people are expecting early on.

 

[Snubbers]

I'm not sure it's valid to just use off the shelf GPU's for comparison, the ESRAM alone is enough of a difference that you can't draw real world comparisons so easily, and that's not to say that the PS4's architecture also is poorly represented by off the shelf GPU's..

As far as I can see, MS could have 'spent' the ESRAM transistors on equaling the PS4 on CU count, with just the RAM bandwidth the main differentiator, but they cut some CU's in favour of the ESRAM based on common usage scenario's they had gathered from 360 development..

I'd say that at this moment, it's impossible to predict the magnitude, I'm honestly not expecting this 50-60% difference people are saying exists based on one or two spec numbers, as in, I will not expect 30fps on XB1 and 60fps on PS4 with identical IQ.. or 720p on XB1 and 1080p on PS4..

 

[SniperHunter]

I don't think Xbone is weak compared to PS4. It runs Ryse with high to very high settings @ 1080p with AA @ 30 FPS and that is great IMO. At the end of the day only a select few Sony devs will use the extra power PS4 has

 

[Ol No Bones]

Looking at the specs we know XB1 is weaker then PS4. The only reason it's more expensive is because of Kinect.

Yes but I'm curious what the real world difference in performance will be. I'm getting both anyway.

 

[RayMaker]

yup. I bought a GPU last year and it packs 3.5 to 4 t flop performance. Both consoles are very weak, let's hope this gen last for 5 years

the 40% isn't bs, its a fact. Deal with it xbottles

Judging by both sony and even more so with MS they want this gen to be the longest ever.

 

[ElTorro]

Again with the 40% BS. Show me BF4 running 40% better on PS4 compared to the Xbone version and I'll gladly eat some crow.

The sentence "Game X will look 40% better" doesn't have meaningful semantics. People are referring to the fact that the PS4's GPU has 50% more ALU (running at 800mhz compared to 853mhz) leading to 41% more programmable raw computation power. Having the same architecture does not mean that those additional 384 ALUs (or "shader cores" or whatever we want to call them) are just there for shits and giggles. It just means that both GPUs are built from the same building blocks, only the PS4 has 50% more of them. That is not controversial, that is just an objective fact. And if those differences are meaningless then I wonder why so many people spend additional money for graphics card from the same vendor and the same family but with more processing power. It's really the same situation. Everybody can take from that what he wants.

 

[SEGAvangelist]

.

 

[tfur]

PS4 XBO Difference
Texture reads(gt/s)...........56........41.....36.59%
Vertex throughput(bn). .....1.6........1.7....-5.88%
Output(gp/s)..................25.6.......13.6....88.24%
Ops/cycle......................1152......768....50.00%
TF................................1.84......1.308...40.67%

I am interested in the sources for some of these numbers. Can you post a link or reference? Thanks.

 

[SniperHunter]

Eeeeek. Isn't that bannable?

sorry, I was just joking

 

[Duxxy3]

Judging by both sony and even more so with MS they want this gen to be the longest ever.

I really hope not. There's already a significant difference between the consoles and PC's, and the consoles aren't even out yet.

 

[cripterion]

The sentence "Game X will look 40% better" doesn't have meaningful semantics. People are referring to the fact that the PS4's GPU has 50% more ALU (running at 800mhz compared to 853mhz) leading to 41% more programmable raw computation power. Having the same architecture does not mean that those additional 384 ALUs (or "shader cores" or whatever we want to call them) are just there for shits and giggles. It just means that both GPUs are built from the same building blocks, only the PS4 has 50% more of them. That is not controversial, that is just an objective fact. And if those differences are meaningless then I wonder why so many people spend additional money for graphics card from the same vendor and the same family but with more processing power. It's really the same situation. Everybody can take from that what he wants.

I'm not denying the specs at all, I'm just laughing at the people that expect 40% more performance because it says so on paper.
Most devs have been saying the PS4 has the lead but that there isn't a huge gap between the consoles so it's funny to see so many people on GAF claiming the PS4 will smash the XBone.

As others have said, the proof is in the pudding and we'll see for ourselves how much better the multiplatforms run on the PS4.

 

[RayMaker]

The sentence "Game X will look 40% better" doesn't have meaningful semantics. People are referring to the fact that the PS4's GPU has 50% more ALU (running at 800mhz compared to 853mhz) leading to 41% more programmable raw computation power. Having the same architecture does not mean that those additional 384 ALUs (or "shader cores" or whatever we want to call them) are just there for shits and giggles. It just means that both GPUs are built from the same building blocks, only the PS4 has 50% more of them. That is not controversial, that is just an objective fact. And if those differences are meaningless then I wonder why so many people spend additional money for graphics card from the same vendor and the same family but with more processing power. It's really the same situation. Everybody can take from that what he wants.

I take it you didnt read Sounddeli post about 1/2 page up.

judging by what he/she is saying the visual difference on the PS4 will be higher res textures. I dont know how you work out how much % better a game looks, but as a guess slightly higher res textures is maybe 5%.

The PS4 could be a 1000tflop beast it does not make any difference if the games only look the same or a little better.

Whats the point in stating a hardware advantage if that advantage does not represent the visual advantage, because afterall that is the whole point in hardware!