But PC CPU's are it really bandwidth bound.... My dual Intel Xenon X5680's don't really seem to be starved of bandwidth no matter what I'm doing.
I'm pulling just shy of 32Gb/s with Tripple channel DDR3
The Next-gen Situation discussion *spawn
- Thread starter gongo
- Start date
But PC CPU's are it really bandwidth bound.... My dual Intel Xenon X5680's don't really seem to be starved of bandwidth no matter what I'm doing.
I'm pulling just shy of 32Gb/s with Tripple channel DDR3
If you only experience software written for a PC environment then how would you know what your dual Intel Xenons could do if they had software written which expected 300GB/s bandwidth? Aren't the algorithms designed around the expected memory address patterns on the platform? If there are other algorithms which could be used but aren't then you'll likely never know.
As for APU vs separate GPU/CPU it is hard to say, I guess it depends on whether good applications for that configuration can be found, I.E. practical GPGPU functions but I suspect an APU would have a significant advantage if they can find something useful for the GPU to do.
As for APU vs separate GPU/CPU it is hard to say, I guess it depends on whether good applications for that configuration can be found, I.E. practical GPGPU functions but I suspect an APU would have a significant advantage if they can find something useful for the GPU to do.
And there lies the weakness in your argument. You use those games as "proof" of the benefits of programming to a single platform but there is no objective measure which claims those games to be any better looking than top tier multiplatform games. You may think those games 'look' better than Crysis 2, Battlefield 3, Assassins Creed 3, Need for Speed Most wanted etc... but that doesn't make it correct.
I take on board your second point which 3dillitante raised earlier about first party devs taking greater advantage of a consoles resources earlier than multiplatform devs, both because of earlier access to dev kits (assuming that is true?) and simply because they only have to learn how to take advantage of one new architecture rather than 2, which is obviously faster. So in the early days, exclusive games may have an advantage over 3rd party games. That said though, you use Gears of War as an example but Gears was built on the multiplatform UE3 engine so it's not as if the engine had been specially taylored to the 360's architecture. If anything it was designed more for the RSX architecture (NV40/G70) and was not much later shown to run just as well on the PS3 in the form of UT3. So the superiority of Gears graphics in this instance could actually be more attributed to the skill of the developers in creating an excellent multiplatform engine and artwork rather than taking any special advantage of the 360's architecture.
If the supposed HSA features enable new rendering tech in next-gen console games, could they still be easily ported to an Intel-dominated PC market? Obviously launch games are being developed on standard PC architectures, but how long until the tech becomes unique to the consoles? Are they going to maintain the legacy renderer for the pc port? Intel would probably have to match or out-do HSA. Assuming all the claims of shared cache and memory and the rest pan out.
I doubt Intel would create a CPU where the performance was that severely limited by bandwidth. If their CPU's could really scale so well with bandwidth then we'd never have lost the 3 memory channels of Nehalem. Even if code of the day didn't take advantage of that bandwidth, it would be worth having it there since new code would certainly take adavntage if there was extra performance to be had.
That said I do agree with your core argument that there are achitectural possibilities with these consoles which may indeed put more powerful PC's at a disadvantage. The obvious one which I've raised before is the large amount of high bandwidth RAM. If a next gen console has say 6GB of memory dedicated to graphics running at say 100GB/s with a whole load of fast edram on top, I'm not sure how something like a 680 with "only" 2GB of dedicated graphics memory could compete with that, even if it does have twice the bandwidth.
We'll never know because of how PC works, there's never truly going to be software that rapes a PC's memory sub system so it's pointless bringing and comparing bandwidth between PC and console.
There's also enough articles that run a multitude of tests on various CPU's at various memory speeds that the difference from the increased bandwidth is practically none existant.
PC's have the bandwidth where it matters, the GPU! My 7970's have over 330Gb/s bandwidth to play with.
When Intel dropped the third channel in Nehalem they didn't have to feed a 2TF integrated GPU.
If back porting to none HSA architectures on the PC really became an issue then AMD and Intel I'm sure would very quickly fill the gap with "gaming" APU's on the PC side. Nvidia seems to be going that route as well. Such APU's could have both faster CPU's and faster GPU's than those in the upcoming consoles thanks to more flexible power limits, higher selling price, binning and ultimately process reductions.
That is of course if HSA becomes such a critical requirement to run next generation games. The death of discrete GPU's would be pretty swift but it certainly wouldn;t mean an end to more capable gaming hardware available in the PC space. In many ways I could see that having big advantages for PC gaming.
Nehalem had 3 channels, Lynnfield, Sandy and Ivy have 2.They didn't drop a channel, they added one
Socket 1155 ( Sandy and Ivy ) didn't replace the Triple channel x58 chipset, the Quad channel x79 chipset did.
Sandy and Ivy were the mid-range replacement for the dual channel P55 chipset.
And sandy and Ivy's memory controller are such a jump over the previous generation that they offer the same bandwidth as the triple channel x58 chipset CPU's.
Agreed, I'm hoping this gen starts an APU arms race and Intel goes all out.
Your mixing the two arguments. I was only commenting on how greater bandwidth would effect CPU performance (i.e. I don't think it would significantly). Obviously greater bandwidth would effect GPU performance but PC GPU's aren't fed through the CPU memory bus, they have their own bus with plenty of dedicated bandwidth.
As already mentioned in the last few posts though, the level of interaction between GPU and CPU in next gen consoles will dictate whether that model is sufficient or if the PC needs to move to a different, more APU like model as it's primary gaming offering.
That's the point, Intel don't see their high end quad cores as needing more bandwidth, hence why they retained the same similar overall level of bandwidth across 2 new iterations (and very possibly across Haswell as well). If bandwidth was that important, i7's would have kept the 3 channels and scaled bandwidth up with memory speed.
I didn't mix the argument, just worded my response badly (scrambling at work in between server builds :smile
. My point was that while 3 channels may have been overkill in Nehalem since they only had to feed the CPU, doesn't mean that future APUs and algorithms won't need a lot more bandwidth. You can't compare Intel's design decisions in a solo CPU (or one with a weak iGPU) to what they will want in the future with graphics are using more and more die area, hence the L4/eDRAM rumors.I didn't mix the argument, just worded my response badly (scrambling at work in between server builds :smile
Yes I completely agree, as APU's get more powerful, more bandwidth will certainly be required. I think we're in agreement though that it's the graphics portion of the APU that will be needing that bandwidth rather than the CPU cores.
That may have been squilliams point in the first place and I've just got the wrong end of the stick.
That would be true if the memory controller in the newer Quad core i7's didn't offer triple Chanel like memory bandwidth.
It's unlikely you could do something that couldn't be achieved in a different way with more raw HP. But more importantly the issue would be the API changes and how long those took to be readily available.
Even if APU's were suddenly in vogue tomorrow and every new PC had one, it would take years before dev's would stop supporting discrete GPU's.
And this is discounting fundamental hardware differences between vendors.
Right now MS could expose an API that would make reading and writing to a texture with the CPU perhaps 100x faster than it currently is, but because of swizzling and tiling the actual format of the texture in memory isn't the same between vendors, so every access has to convert in both directions. Putting everything in the same memory pool on a PC doesn't resolve that. On a console you can do it, because you simply document the the required format.
The CPUs themselves are designed to make better use of limited memory bandwidth and the software is designed to not use too much memory bandwidth because there would be no advantage to do so. If a major software development house would never create software which was severely bandwidth constrained if they had an option to do otherwise because it would be stupid then how could you find software written for PCs which is bandwidth constrained? Software written for a different architecture which has more memory bandwidth could be written differently so the real question is when this software is ported back from a console with a lot of memory bandwidth and was designed with this bandwidth in mind, how will it run then?
There's other factors, PC have more raw power and generally much larger caches....
Just because a piece of software uses 'x' amount of bandwidth doesn't meen that its using it efficiently.
360's CPU arguably has half the bandwidth of Cell and it seems to be coping just fine, showing that even in a console CPU bandwidth is hardly ever the main problem, thinking back I can't think of any console that had a CPU that's been bandwidth bound.