Support NeoGAF

[derFeef]

I've always wanted to play that gears of war kinect title.

I am not sure I wanted to play it, but I wanted to see it.
It must have been a really tight decision to not show it - and cancel it (if it even was a thing).

 

[Clay Davis]

So did anything happen during the open house event in Mountain View?

nope. you'd know if it did, there would have been a thread.

I am not sure I wanted to play it, but I wanted to see it.
It must have been a really tight decision to not show it - and cancel it (if it even was a thing).

this is a good point, we don't really know if it ever was actually in development. with american nightmare, we had leaks of the title screen, etc but with exile, there was nothing outside of a logo and confirmation that a title called exile was in development.

 

[brain_stew]

Not quite, it represents a difference in raw float point throughput, how that throughput translates to performance is a whole different ball game.

And that's not even talking about efficiency, difference in architectures... Your work simply might not need the extra operations. Say for example that all you want to do is to draw big black images as fast as you can. The performance won't be determined by the flop rate at all.

Of course, there's not much use in big black images, but not every game is going to be hold back by alu performance, heck even in some fairly high profile games in this generation developers have come out and said that they still some processing power unused on 7 year old hardwares (360 and Ps3) and that they can't put that to good use because they are being hold back by their memory.

My point is: Not knowing all the details of the architectures means we can't say precisely where each of them is going to have an advantage over the other. Not knowing which kind of games these consoles are going to run means we can't say pretty much nothing about their final performance. Say in a hypothetical scenario Orbis massive bandwidth gives it an immense edge over durango in deferred rendering. But for some reason developers decide to stick to forward rendering (be it lowest common denominator, gpgpu being used in a way where they can have the forward rendering advantages and the deferred ones too, etc) and in forward rendering orbis extra bandwidth doesn't make much a difference, but durango's memory setup allows it to compensate the float point advantage and then some, but by a smaller margin then DF would yield, so developers decide to stick to that for parity's sake.

Even if a company design a game console that can excel at current games doesn't mean it will hold true to games in 2-3 years or more. That kinda happened with 360. It's edram setup was less than ideal for deferred rendering, and even it's biggest advantage over Ps3 (lower cost MSAA) was pretty much nullified, and with MLAA there were actually some cases were Ps3 turned the table in it's favor...



Not to enter in a Ps3 vs 360 debate that later on the generation, but those flops figures on RSX are simply not true.

RSX in fact very close to xenos in theorical float point performance (regarding pixel shading).

The "theorical" performance gets inflated because people assume they can simply add all the units that execute operations, but by design of the architecture they are not addable.

An oversimplified quick example: RSX has 8 vertex shading units, usually those flop figures add those to the pixel shading ones. But during a frame usually you do vertex processing before you do any pixel processing, so in reality when a game is drawing it's geometry the weak (in comparison to the pixel shaders) are actually stalling the pixel shader units that have to sit there waiting for it to finish so they can start their work. On xenos that's not a problem because all it's execution units can be dedicated to the vertex processing, so xenos ends that job more quickly and gets more time to do pixel shading work, and so, even though they have theoretical close performance to RSX's pixel shaders they can achieve a higher throughput.

Sony and Microsoft are using the same partner and same generation of hardware this time though, there isn't any logical reason to suspect one part is noticeably more efficient than the other.

Comparing teraflops and compute units isn't about comparing a single metric either, as we all know AMD scale the entire pipeline up as they increase compute units. Yet this fact is constantly brushed over. The safest and most logical assumption would be that every other performance metric to do with the GPU is also around 50% faster. Considering we already know that main memory bandwidth ruins 300% faster and that Durango has fewer CPU resources dedicated to games, you're expecting an awful lot from 32MB of eSRAM, " data move engines" and some low level tweaks to the same GPU architecture if you think Durango is even going to be in the same ballpark as Orbis.

Let's play devil's advocate here though and assume those tweaks really were so incredible that they overcame such a massive deficit. If that's the case then why were they not offered to Sony? Why have they never appeared on the PC before? And why are we writing off the fact that Sony have performed custom tweaks of their own?

A lot of people tout the fact that more engineers worked on Microsoft's project but that was always going to be the case. Microsoft don't have nearly as many hardware engineers with years of experience designing consoles and SOCs, they rely on their partners to provide the " glue" that links the main components. Sony can do most of that work inhouse like they have always done.

 

[derFeef]

Poor Durango and MS, does not sound good at all.

 

[ekim]

Well... I'm biased towards the Xbox brand simply because of the (in my opinion) superior controller and OS on the 360. But if Durango really turns out to be more like a media box... let's wait and see.

 

[specialguy]

Sony and Microsoft are using the same partner and same generation of hardware this time though, there isn't any logical reason to suspect one part is noticeably more efficient than the other.

Comparing teraflops and compute units isn't about comparing a single metric either, as we all know AMD scale the entire pipeline up as they increase compute units. Yet this fact is constantly brushed over. The safest and most logical assumption would be that every other performance metric to do with the GPU is also around 50% faster. Considering we already know that main memory bandwidth ruins 300% faster and that Durango has fewer CPU resources dedicated to games, you're expecting an awful lot from 32MB of eSRAM, " data move engines" and some low level tweaks to the same GPU architecture if you think Durango is even going to be in the same ballpark as Orbis.

Let's play devil's advocate here though and assume those tweaks really were so incredible that they overcame such a massive deficit. If that's the case then why were they not offered to Sony, why have they never appeared on the PC before and why are we don't writing of the fact that Sony have performed custom tweaks of their own?

A lot of people tout the fact that more engineers worked on Microsoft's project but that was always going to be the case. Microsoft don't have nearly as many hardware engineers with years of experience designing consoles and SOCs, they rely on their partners to provide the " glue" that links the main components. Sony can do most of that work inhouse like they have always done.

50% less shaders (assuming theres no secret sauce to make up any of that)
43% more RAM (with possible potential for even more if OS reserves are reduced in the future)
Exact same CPU (possibly more cores OS reserved, but possibly a better audio chip as well, but if you argue Cell>Xcpu, Xbox is in a better CPU position this gen)
Kinect and OS features drawing in casuals
Multiplatform games likely showing little difference. Xbox had >50% better GPU than PS2, plus double the RAM. It got mostly PS2 ports.
lack of devs saying PS4>Durango, lherre saying they are comparable to PS3 vs 360.

I'm pretty sure rumors of Durango's demise are greatly exaggerated.

Plus, as always, I think we should wait for games. It's the only way for example to tell if "secret sauce" is real, on either side. If Durango titles mysteriously look just as good as Orbis ones...it's the only way to tell how these various components mesh in the real world.

 

[Reiko]

Man if the specs have been significantly bumped down or bumped up, this thread will be hilarious to read going back.

 

[Proelite]

Man if the specs have been significantly bumped down or bumped up, this thread will be hilarious to read going back.

This thread is already hilarious to read.

 

[derFeef]

This thread is already hilarious to read.

Only if you know stuff others don't, I guess.
Or to act as if...

 

[Durante]

Sony and Microsoft are using the same partner and same generation of hardware this time though, there isn't any logical reason to suspect one part is noticeably more efficient than the other.

Comparing teraflops and compute units isn't about comparing a single metric either, as we all know AMD scale the entire pipeline up as they increase compute units. Yet this fact is constantly brushed over. The safest and most logical assumption would be that every other performance metric to do with the GPU is also around 50% faster. Considering we already know that main memory bandwidth ruins 300% faster and that Durango has fewer CPU resources dedicated to games, you're expecting an awful lot from 32MB of eSRAM, " data move engines" and some low level tweaks to the same GPU architecture if you think Durango is even going to be in the same ballpark as Orbis.

Let's play devil's advocate here though and assume those tweaks really were so incredible that they overcame such a massive deficit. If that's the case then why were they not offered to Sony? Why have they never appeared on the PC before? And why are we writing off the fact that Sony have performed custom tweaks of their own?

A lot of people tout the fact that more engineers worked on Microsoft's project but that was always going to be the case. Microsoft don't have nearly as many hardware engineers with years of experience designing consoles and SOCs, they rely on their partners to provide the " glue" that links the main components. Sony can do most of that work inhouse like they have always done.

Good points. About the "more engineers" issue, I think it's important to keep in mind that MS is using embedded memory, which AMD had never used in a GCN-based GPU before, so that by itself should already significantly increase the engineering effort compared to a "plain" (but fast) GDDR5 bus.

 

[Psychotext]

Man if the specs have been significantly bumped down or bumped up, this thread will be hilarious to read going back.

Wont really make a difference though. It's clear that a lot of people have already drawn their lines in the sand and even if we get devs coming out saying that one is better than the other / the same / roughly the same you'll just have posters saying the dev is lying for whatever reason... or incompetent.

There's already an insane amount of hyperbole floating around and the machines aren't even announced yet!

 

[ekim]

Wont really make a difference though. It's clear that a lot of people have already drawn their lines in the sand and even if we get devs coming out saying that one is better than the other / the same / roughly the same you'll just have posters saying the dev is lying for whatever reason... or incompetent.

There's already an insane amount of hyperbole floating around and the machines aren't even announced yet!

How was it the last time (360 / PS3)? I wasn't around here that time.

 

[Psychotext]

I don't recall it being this bad, but then I also don't recall leaks like this.

Was a bloody long time ago!

 

[Pooya]

Man if the specs have been significantly bumped down or bumped up, this thread will be hilarious to read going back.

Wii U spec threads were fun in perspective :lol

 

[Reiko]

How was it the last time (360 / PS3)? I wasn't around here that time.

Same as it was now.

 

[Cyborg]

This hype is bullshit........only rumors and nothing concrete!
Disappointment is bound to happen!

 

[derFeef]

Wan't it the exact same thing? "Xbox 1.5" and stuff?

 

[brain_stew]

50% less shaders (assuming theres no secret sauce to make up any of that)
43% more RAM (with possible potential for even more if OS reserves are reduced in the future)
Exact same CPU (possibly more cores OS reserved, but possibly a better audio chip as well, but if you argue Cell>Xcpu, Xbox is in a better CPU position this gen)
Kinect and OS features drawing in casuals
Multiplatform games likely showing little difference. Xbox had >50% better GPU than PS2, plus double the RAM. It got mostly PS2 ports.
lack of devs saying PS4>Durango, lherre saying they are comparable to PS3 vs 360.

I'm pretty sure rumors of Durango's demise are greatly exaggerated.

Plus, as always, I think we should wait for games. It's the only way for example to tell if "secret sauce" is real, on either side. If Durango titles mysteriously look just as good as Orbis ones...it's the only way to tell how these various components mesh in the real world.

I'm not arguing about the market impact of these hardware choices.

 

[Psychotext]

Wan't it the exact same thing? "Xbox 1.5" and stuff?

That was after announcement though. Largely due to CGI trailers vs (unimpressive) gameplay. Sony played that aspect perfectly.

 

[JAYSIMPLE]

So is the next xbox the 360 1.5 then? lol are we getting that again?

 

[derFeef]

That was after announcement though. Largely due to CGI trailers vs (unimpressive) gameplay. Sony played that aspect perfectly.

Ah, no idea, wasnt here back then. I only saw Gears of War gameplay and ordered that thing

 

[Ashes]

I do wonder what Microsoft's reaction was to the supposed next gen Samaritan demo. Who commissioned that. Was it Nvidia? Epic? Valve? Sony? Microsoft?

 

[specialguy]

Considering we already know that main memory bandwidth ruins 300% faster and that Durango has fewer CPU resources dedicated to games, you're expecting an awful lot from 32MB of eSRAM, " data move engines" and some low level tweaks to the same GPU architecture if you think Durango is even going to be in the same ballpark as Orbis.

It runs faster and should be able to do amazing things, but it's still a hefty amount less than in Durango. And if that post I posted from sebbi is correct, most games have a "working set" of RAM ~3X what is used per frame.

So to me that fits a lot better with 5GB/2GB per frame than 3.5GB/3.5GB per frame.

If, lets say the ESRAM/other stuff can even get Durango up to the point where it can use it's memory just as fully as PS4, I'd be happy with that and call it a wash. I think one system with 50% more shaders and another with 43% more RAM are a wash, provided everything else is fairly equal, meaning provided that in the end Durango can basically use it's RAM just as well as PS4 can thx to it's helpers.

I also still have a funny feeling Orbis downgrades might be coming, just because Sony has a long history of screwing stuff up in an incredibly stupid manner. Imagine the shocker if they go back to 2GB. Not saying that'll happen, but I would say "that's Sony!" if they did.

 

[Pooya]

well, there wasn't much expectations from 360 then, it was labeled Dreamcast 2.0 by 1up and Xbox 1.5 by everyone else, games looked not so hot either, it was perceived as failure by everyone, I think the debates are going to be far more tense here in coming months than that time when things start rolling

 

[Reiko]

With the amount of hype I'm seeing from both of these specs... The first DF multiplat comparisons will not end well. I'm pretty sure someone will be called out for being biased, lazy, inept... etc

 

[Karma]

Sony and Microsoft are using the same partner and same generation of hardware this time though, there isn't any logical reason to suspect one part is noticeably more efficient than the other.

Comparing teraflops and compute units isn't about comparing a single metric either, as we all know AMD scale the entire pipeline up as they increase compute units. Yet this fact is constantly brushed over. The safest and most logical assumption would be that every other performance metric to do with the GPU is also around 50% faster. Considering we already know that main memory bandwidth ruins 300% faster and that Durango has fewer CPU resources dedicated to games, you're expecting an awful lot from 32MB of eSRAM, " data move engines" and some low level tweaks to the same GPU architecture if you think Durango is even going to be in the same ballpark as Orbis.

We don't know anything. This is all rumor or even disinformation.

 

[Ashes]

It runs faster and should be able to do amazing things, but it's still a hefty amount less than in Durango. And if that post I posted from sebbi is correct, most games have a "working set" of RAM ~3X what is used per frame.

So to me that fits a lot better with 5GB/2GB per frame than 3.5GB/3.5GB per frame.

If, lets say the ESRAM/other stuff can even get Durango up to the point where it can use it's memory just as fully as PS4, I'd be happy with that and call it a wash. I think one system with 50% more shaders and another with 43% more RAM are a wash, provided everything else is fairly equal, meaning provided that in the end Durango can basically use it's RAM just as well as PS4 can thx to it's helpers.

I also still have a funny feeling Orbis downgrades might be coming, just because Sony has a long history of screwing stuff up in an incredibly stupid manner. Imagine the shocker if they go back to 2GB. Not saying that'll happen, but I would say "that's Sony!" if they did.

This one?

here's that sebbi post

http://forum.beyond3d.com/showthread.php?t=62108&highlight=sebbi

The next gen speculation thread started to have interesting debate about memory bandwidth vs memory amount. I don't personally want to contribute to the next gen speculation, but the "memory bandwidth vs memory amount" topic is very interesting in it's own. So I decided to make a thread for this topic, as I have personally been doing a lot of memory access and bandwidth analysis lately for our console technology, and I have programmed our virtual texturing system (and many other JIT data streaming components).

Historically memory performance has improved linearly (very slowly) compared to exponential (Moore's law) growth of CPU performance. Relative memory access times (latencies) have grown to be over 400x higher (in clock cycles) compared to first PC computers, and there's no signs that this development will slow down in the future, unless we invent some radically new ways of storing data. None of the currently known future technologies is going to solve the problem, just provide some band aid. So we need to adapt.

Some links to background information first:

1. Presentation by Sony R&D. Targeted for game technology programmers. Has a very good real life example how improving your memory access pattern can improve your performance by almost 10x. Also has nice charts (slides 17 and 18) showing how memory speed has increased historically compared to ALU:
http://harmful.cat-v.org/software/OO...ng_GCAP_09.pdf

2. Benchmark results of a brand new x86 chip with unified memory architecture (CPU & GPU share the same memory & memory controller). Benchmark shows system performance with all available DDR3 speeds from DDR3-800 to DDR3-1866. All other system settings are identical, only memory bus bandwidth is scaled up/down. We can see an 80% performance (fps) improvement in the gaming benchmark just by increasing the DDR3 memory clock:
http://www.tomshardware.com/reviews/...0k,3224-5.html

3. A GPU benchmark comparing old Geforce GTS 450 (1 GB, GDDR5) card to a brand new Kepler based Geforce GT 640 (2 GB, DDR3). The new Kepler based card has twice the memory amount and twice the ALU performance, but only half of the memory bandwidth (because of DDR3). Despite the much faster theoretical shader performance and twice the memory amount, it loses pretty badly in the benchmarks because of it's slower memory bus:
http://www.anandtech.com/show/5969/z...gt-640-review-

Quote:
Originally Posted by aaronspink View Post
In the console space, using 2GB as a disk cache alone will make for a better end user experience than 2x or even 3-4x gpu performance.
I completely disagree with this. And I try now to explain why. As a professional, you of course know most of the background facts, but I need to explain that first, so that my remarks later aren't standing without a factual base.

--- ---

I will use the x86 based Trinity APU [link 2] as my example system, as it has close enough performance and memory bandwidth compared to current generation consoles (it's only around 2x-4x faster overall) and it has unified memory (single memory bus shared between CPU & GPU). It's much easier to talk about a well known system, with lots of public benchmarks results around the net.

Let's assume we are developing a vsync locked 60 fps game, so each frame must complete in 16.6 ms time. Let's assume our Trinity system is equipped with the fastest DDR3 it supports (DDR3-1866). According to Tom's Hardware synthetic bandwidth benchmark, this configuration gives us 14 GB bandwidth per second. Divide that by 60, and we get 233 MB bandwidth per frame. Let's round that down to even 200 MB per frame to ease up our calculations. A real game newer utilizes memory bandwidth as well as a synthetic benchmark, so even the 200 MB per frame figure is optimistic.

Now I know that my game should never access more than 200 MB of unique memory per frame if I want to reach my vsync locked 60 fps. If I access more memory, my frame rate dips as the memory subsystem cannot give me enough data, and my CPU & GPU start stalling.

How about CPU & GPU caches? Caches only help with repeated data access to the same data. Caches do not allow us to access any more unique data per frame. Also it's worth noticing that if you access the same memory for example at beginning of your frame, at middle of your frame and at end of your frame, you will pay as much as if you did three unique memory accesses. Caches are very small, and old data gets replaced very fast. Our Trinity CPU has 4 MB of L2 cache and we move 200 MB of data to the cache every frame. Our cache gets fully replaced by new data (200/4 =) 50 times every frame. Data only stays in cache for 0.33 ms. If we access it again after this period, we must fetch it from the memory again (wasting our valuable 200 MB per frame bandwidth). It's not uncommon that a real game accesses every data in the current working set (on average) twice per frame, leaving us with 100 MB per frame unique accessible memory. Examples: Shadowmaps are first rendered (to textures in memory) and sampled later during lighting pass. Physics simulation moves objects (positions & rotations) and later in frame those same objects are rendered (accessing those same position and rotation datas again).

However let's keep the theoretical 200 MB per frame number, as engines differ, and access patterns differ (and we do not really want to got that far in the analysis). In a real game you can likely access only around 100 MB - 150 MB of unique memory per frame, so the forthcoming analysis is optimistic. A real game could likely access less memory and thus have a smaller working set.

So far we know that the processing and rendering of a single frame never requires more than 200 MB of memory (we can't reach 60 fps otherwise). If your game has a static scene, you will not need more memory than that. However static scenes are not much fun, and thus this scenario is highly unlikely in real games (except for maybe a chess game with a fixed camera). So the billion dollar question becomes, how much does the working set (memory accesses) change from frame to frame in a 60 fps game?

In a computer game, objects and cameras do not really "move" around, they get repositioned every frame. In order for this repositioning to look like smooth movement we can only change the positions very slightly from frame to frame. This basically means that our working set can only change slightly from frame to frame. According to my analysis (for our game), our working set changes around 1%-2% per frame in general case, and peaks at around 10%. Especially notable fact is that our virtual texturing system working set never changes more than 2% per frame (textures are the biggest memory user in most games).

We assume that a game with a similar memory access pattern (similarly changing working set from frame to frame) is running on our Trinity example platform. Basically this means that in average case our working set changes from 2 MB to 4 MB per frame, and it peaks at around 20 MB per frame. We can stream this much data from a standard HDD. However HDDs have long latencies, and long seek times, so we must stream data in advance and bundle data in slightly bigger chunks than we like to combat the slow seek time. Both streaming in advance (prefetching) and loading in bigger chunks (loading slightly wider working set) require extra memory. Question becomes, how much larger the memory cache needs to be than our working set?

The working set is 200 MB (if we want to reach that 60 fps on the imaginary game on our Trinity platform). How much more memory we need for the cache? Is working set x2.5 enough (512 MB)? How about 5x (1 GB) or 10x (2 GB)?

Our virtual texture system has a static 1024 page cache (128x128 pixel pages, 2x DXT5 compressed layer per page). Our average working set per frame is around 200-400 pages, and it peaks as high as 600 pages. The cache is so small that it has to reload all textures if you spin the camera around in 360 degrees, but this doesn't matter, as the HDD streaming speed is enough to push new data in at steady pace. You never see any texture popping when rotating or moving the camera. The only occasion where you see texture popping is when the camera suddenly teleports to a completely different location (working set changes almost completely). In our game this only happens if you restart to a checkpoint or restart the level completely, so it's not a big deal (and we can predict it).

If the game behaves similarly to our existing console game, we need a cache size of around 3x the working set for texture data. Big percentage of the memory accessed per frame (or stored to the memory) goes to the textures. If we assume for a moment that all other memory accesses are as stable as texture accesses (cache multiplier of 3x) we only need 600 MB of memory for a fully working game. For some memory bandwidth hungry parts of the game this actually is true. And things are even better for some parts: shadow maps, post processing buffers, back buffer, etc are fully generated again every frame, so we need no extra memory storage to hold caches of these (cache multiplier is 1x).

Game logic streaming is a harder thing to analyze and generalize. For example our console game has a large free roaming outdoor world. It's nowhere as big as worlds in Skyrim for example, but the key point here is that we only keep a slice of the world in memory at once so the world size could theoretically be limitless (with no extra memory cost). Our view distance is 2 kilometers, so we do need to keep full representation of the game world in memory after that. Data quality required for a distance follows pretty much logarithmic scale (texture mip mapping, object geometry quality, heightfield quality, vegetation map quality, etc etc). Data required as distance grows shrinks dramatically. This is of course only true for easy cases such as graphics processing, heightfields, etc. Game logic doesn't automatically scale. However you must scale it manually to reach that 200 MB per frame memory access limit. Your game would slow down to halt if you just tried to simply read full AI data from every single individual NPC in the large scale world, no matter how simple your processing would be.

Our heightmap cache (used in physics, raycasts and terrain visualization) keeps around 4x the working set. We do physics simulation (and exact collision) only for things near the player (100 meters max). When an object enters this area, we add corresponding physics objects to our physics world. It's hard to exactly estimate how big percentage of our physics world structures are accessed per frame, but I would estimate around 10%. So we basially have a 10x working set "cache" for physics.

Basically no component in our game required more than 10x memory compared to its working set. Average requirement was around 3x. So theoretically a game with similar memory access patterns would only need 600 MB of memory on our example Trinity platform. And this includes as much texture resolution as you ever want (virtual texturing works that way). And it includes as much other (physics, game logic, etc) data as you can process per frame (given the limited bandwidth). Of course another game might need for example average of 10x working set for caches, but that's still only 2 GB. Assuming game is properly optimized (predictable memory accesses are must have for good performance) and utilizes JIT streaming well, it will not benefit much if we add more main memory to our Trinity platform beyond that 2 GB.

More memory of course makes developers life easier. Predicting data access patterns can be very hard for some styles of games and structures. But mindlessly increasing the cache sizes much beyond working set sizes doesn't help either (as we all know that increasing cache size beyond working set size gives on average only logarithmic improvement on cache hit rate = diminishing returns very quickly).

My conclusion: Usable memory amount is very much tied to available memory bandwidth. More bandwidth allows the games to access more memory. So it's kind of counterintuitive to swap faster smaller memory to a slower larger one. More available memory means that I want to access more memory, but in reality the slower bandwidth allows me to access less. So the percentage of accessible memory drops radically.

Although it's notable rereading it he seems to ask for 2-3X+ RAM as accessible per frame, which actually seems more like Durango's setup.

Did you look at his memory controller?

Edit: Reading it again, his conclusion is different to yours. And closer to what one would expect:

In conclusion: Usable memory amount is very much tied to available memory bandwidth. More bandwidth allows the games to access more memory. So it's kind of counterintuitive to swap faster smaller memory to a slower larger one. More available memory means that I want to access more memory, but in reality the slower bandwidth allows me to access less. So the percentage of accessible memory drops radically.

 

[scently]

well, there wasn't much expectations from 360 then, it was labeled Dreamcast 2.0 by 1up and Xbox 1.5 by everyone else, games looked not so hot either, it was perceived as failure by everyone, I think the debates are going to be far more tense here in coming months than that time when things start rolling

Indeed. Everybody just seem to ignore the fact that a developer with access to both systems have already said that both systems are very close. I will much rather believe what he has said.

Btw, the fact that they are both getting their parts from the same vendor doesn't mean that they get the same stuff, it really all depends on what they want and how customized and different they want it to be.

 

[LukasTaves]

Sony and Microsoft are using the same partner and same generation of hardware this time though, there isn't any logical reason to suspect one part is noticeably more efficient than the other.

Comparing teraflops and compute units isn't about comparing a single metric either, as we all know AMD scale the entire pipeline up as they increase compute units. Yet this fact is constantly brushed over. The safest and most logical assumption would be that every other performance metric to do with the GPU is also around 50% faster. Considering we already know that main memory bandwidth ruins 300% faster and that Durango has fewer CPU resources dedicated to games, you're expecting an awful lot from 32MB of eSRAM, " data move engines" and some low level tweaks to the same GPU architecture if you think Durango is even going to be in the same ballpark as Orbis.

Let's play devil's advocate here though and assume those tweaks really were so incredible that they overcame such a massive deficit. If that's the case then why were they not offered to Sony? Why have they never appeared on the PC before? And why are we writing off the fact that Sony have performed custom tweaks of their own?

A lot of people tout the fact that more engineers worked on Microsoft's project but that was always going to be the case. Microsoft don't have nearly as many hardware engineers with years of experience designing consoles and SOCs, they rely on their partners to provide the " glue" that links the main components. Sony can do most of that work inhouse like they have always done.

I'm not even talking about architecture optimizations, I'm talking about workload favoring one over another.

What if even the 1.8tf of orbis is not enough for what developers want to do with completely dynamic lighting, and as a result they decide to pre bake everything, and using tons of memory they can get a lighting that looks so much better, without losing much of the interactive part? Just like that and a game that could potentially be ALU bound shifts towards being memory bound, and in that case durango has at least a advantage as big as orbis has in float point performance, and it could grow even more as the generation passes.

 

[Durante]

That post by sebbi, and his subsequent posts in the linked thread, are fantastic. I actually remember his nick from back when I was active on B3D. Thanks for linking that, it was a great read.

 

[szaromir]

Same as it was now.

It was much, much worse back in 2005-2007.

 

[Ashes]

That post by sebbi, and his subsequent posts in the linked thread, are fantastic. I actually remember his nick from back when I was active on B3D. Thanks for linking that, it was a great read.

And what, out of interest do you, draw from his writeup?
Would love to have more opinions on this.

 

[Durante]

And what, out of interest do you, draw from his writeup?
Would love to have more opinions on this.

Well, the more interesting things I draw from all his posts in that thread are optimization ideas, but I guess that's not what you're asking.

As it pertains to next-gen consoles, what I'd draw from his posts is that as long as you competently implement streaming / virtual texturing, a 3.5 GB capacity limit should not be an issue at all.

 

[Ashes]

Well, the more interesting things I draw from all his posts in that thread are optimization ideas, but I guess that's not what you're asking.

As it pertains to next-gen consoles, what I'd draw from his posts is that as long as you competently implement streaming / virtual texturing, a 3.5 GB capacity limit should not be an issue at all.

Oh no, Durango has made interesting choices, choices I cannot reason with yet, nor match dev suggestions of rough equality between the two consoles, so please, feel free...

 

[Reiko]

It was much, much worse back in 2005-2007.

Coming from PS2... It sure would be.

 

[Sorc3r3r]

With the amount of hype I'm seeing from both of these specs... The first DF multiplat comparisons will not end well. I'm pretty sure someone will be called out for being biased, lazy, inept... etc

Multi will always be made out of compromises.
If here someone is expecting 3rd party games to be upgraded or tailored to fit the 2 console specifications, must be prepared to be deluded, not a dollar will be used more of what is strictly needed to make a port.

1st party games instead will shine the next, even more than they have this one.

 

[runningjoke]

I do wonder what Microsoft's reaction was to the supposed next gen Samaritan demo. Who commissioned that. Was it Nvidia? Epic? Valve? Sony? Microsoft?

Probably Epic. They need a tech demo to show people so they can sell their middleware to them. Releasing it to the general public to generate hype also doesn't hurt.

 

[szaromir]

My conclusion: Usable memory amount is very much tied to available memory bandwidth. More bandwidth allows the games to access more memory. So it's kind of counterintuitive to swap faster smaller memory to a slower larger one. More available memory means that I want to access more memory, but in reality the slower bandwidth allows me to access less. So the percentage of accessible memory drops radically.

That's why consoles always went for small but fast memory pools. No surprises here. What's puzzling is Durango's setup.

Multi will always be made out of compromises.
If here someone is expecting 3rd parties games to be upgraded or tailored to fit the 2 console specifications, must be prepared to be deluded, not a dollar willl be used more of what is strictly needed to make a port.

If Orbis is indeed quite a bit more powerful but with similar architecture, then I can imagine it'll have 'easy' improvements like higher resolution, better texture filtering, better shadows etc. You can have much better graphics that way without spending a dime more on art assets.

 

[nelsonroyale]

Oh no, Durango has made interesting choices, choices I cannot reason with yet, nor match dev suggestions of rough equality between the two consoles, so please, feel free...

Surely the reasoning seems to be balancing budget against performance? They want to get maximum performance out of relatively middling specs. Otherwise, why not just go with a more powerful GPU?

 

[spwolf]

And what, out of interest do you, draw from his writeup?
Would love to have more opinions on this.

only possible?

 

[derFeef]

Surely the reasoning seems to be balancing budget against performance? They want to get maximum performance out of relatively middling specs. Otherwise, why not just go with a more powerful GPU?

smaller amount of DDR5 + no eSRAM = probably about the same cost and more effective.

 

[Durante]

Well, the effective maximum for GDDR5 seems to be 4 GB, and if you really want to use 2-3 GB for your OS that's clearly a no-go.

Really, the big mystery is what you could ever need so much OS memory for.

 

[szaromir]

Well, the effective maximum for GDDR5 seems to be 4 GB, and if you really want to use 2-3 GB for your OS that's clearly a no-go.

Really, the big mystery is what you could ever need so much OS memory for.

Isn't Windows 8 fine with just 1GB of RAM? Considering how feature-rich it is and how many features a console could be stripped from, 3GB for a console OS is very puzzling indeed.

 

[itsgreen]

Well, the effective maximum for GDDR5 seems to be 4 GB, and if you really want to use 2-3 GB for your OS that's clearly a no-go.

Really, the big mystery is what you could ever need so much OS memory for.

Hardly a big mystery.

Running multiple high fidelity background apps at the same time (as a game)... even my phone has 2GB of ram...

 

[ekim]

Well, the effective maximum for GDDR5 seems to be 4 GB, and if you really want to use 2-3 GB for your OS that's clearly a no-go.

Really, the big mystery is what you could ever need so much OS memory for.

Do we really know that 2-3 GB are reserved for the OS?

 

[Pooya]

If all of those things I read about DMEs people talking here (which frankly I think effectiveness of such setup is quite dubious), the circuitry of Durango must be quite a bit more complicated, right now I think it's probably more expensive actually, maybe by not much.

no OS feature would need 3GB of RAM. The only thing I can think of is maybe the real time 3D image of Kinect in very very high resolution could takes GBs of RAM to store, to provide the precision Kinect lacks right now, even then the bandwidth might be bad for latency and responsiveness of that too, but probably won't be as important as game frame buffer and performance of real time rendering.

 

[Ashes]

Well, the effective maximum for GDDR5 seems to be 4 GB, and if you really want to use 2-3 GB for your OS that's clearly a no-go.

Really, the big mystery is what you could ever need so much OS memory for.

oh.. interesting.. So what you're saying is that Microsoft could have gone with either 4 gb gddr5 or 8 gb ddr3 setup, but because their designs had 3 gb ram allocation for the OS, they were hamstrung - unless they find either a hardware solution or a manufacturing solution.

When you put it that way, it makes all the more sense.

Hmm... interesting. Metro 8 RT incoming? to make all x3 connected tvs 'smart' and internet ready.

 

[gofreak]

I think we shouldn't be thinking 'what OS feature could possibly need 2.5-3GB of RAM?' and start thinking more along the lines of multiple features and apps running in parallel with a game, possibly Windows Store/RT related apps, with the design aimed at offering that kind of experience with windows apps over the next few years (hence, perhaps, wanting to have a bit of cushion). IMO it's not hard to imagine MS wanting around 2GB for something like a windows app sandbox on 720, with maybe half a gig for other more 720-specific processes/features.

 

[Pooya]

I think we shouldn't be thinking 'what OS feature could possibly need 2.5-3GB of RAM?' and start thinking more along the lines of multiple features and apps running in parallel with a game, possibly Windows Store/RT related apps, with the design aimed at offering that kind of experience with windows apps over the next few years (hence, perhaps, wanting to have a bit of cushion). IMO it's not hard to imagine MS wanting around 2GB for something like a windows app sandbox on 720, with maybe half a gig for other more 720-specific processes/features.

no amount of windows apps running at the same time would need 2GB of RAM, right now in Windows 8 assuming they are using same Modern App system, you can run only two apps at the same time, any app not present on the screen goes into freeze state, unloaded from memory, basically taking next to no memory until it's restored again. Looking at my task manager right now basically all of metro apps are 'running' but take no memory unless you're using them on the screen. You can multitask and switch all you want, I'm not sure why their possible system in a console wouldn't be as efficient.

 

[Ashes]

They can have their 'Siri' with Kinect. Already possible but much more dooable if every console comes with Kinect.

Well, let's go crazy and suggest a hardcore v casual crowd with two consoles sku.

X3 + Kinect 2 = $299
X3 + 500gb hd = $299