-Fran- :
gamerk316 :
Lets not forget the old consoles had only 3 real cores at maximum, the new consoles are sporting 8.
No.
For the last time, the PS3 had a single PPE with 8 SPE elements, one reserved for the OS, one disabled due to yields, leaving SIX SPE elements for developers to play with. The 360 had a tri-core CPU with 2-way SMT support, enabling up to 6 threads to be executed at a time in hardware.
I just laugh when people don't know what they are talking about, and repeat the arguments made back in 2006 when the 360/PS3 hardware started to get leaked.
Well, the SPE's are not general purpose CPUs per sè, so you don't really have "6 cores" in the PS3. I get your point, but in the particular case of the PS3, it's kind of over simplified, my friend.
Other than that, the SMT in the XB360 is close to what you get with HT in desktop CPUs I'd say, so not *really* 6 cores. More like 3 heavy duty cores and 3 "spare parts", haha. Yeah, yeah, just bare with me on that
Cheers!
I did simplify the SPE example a bit, but at the end of the day, its boils down to 6 execution units which each have their own local memory. And SMT on the PPC arch is implemented differently then HTT on X86. 80-90% performance on the second execution unit is normal, which is higher then AMD's CMT implementation.
He's fixated on it because Crysis 3 is a game that totally broke his "games can't use more then 1~2 cores!" statement. Essentially Gamer was making the argument that the only performance that really mattered was single thread performance because programs are too hard to make work multi-threaded.
Understand what Crysis 3 did. The developers didn't take the engine and make it scale to more cores, they simply moved more work to the CPU. There's a difference between making the engine scale versus simply doing more work.
Crysis 3 is actually an interesting test case, per ananad:
Based on a quick analysis, it looks like one main thread, nine helpers, and the main render thread. So 11 threads doing significant (>5% load) amounts of work. But notice the periods where ALL of the threads are NOT executing? Thats generally the sign of some other bottleneck. In this case, the GPU (as expected; all games GPU bottleneck at max settings).
Compare that to Unigine:
A more traditional two thread approach: the main execution thread, and the main render thread. And note the clear GPU bottleneck.
My point is this: No matter what you do CPU side, it DOESN'T AFFECT PERFORMANCE. Why? Because the GPU is the bottleneck. So either you have to move more work to the CPU from the GPU, or increase GPU power. Nothing else is going to push performance upward, because the CPU is spending ~75% of its time doing NOTHING.
Thats the issue.
The lack of threading isn't the problem; the GPU being overworked is the problem.
The primary problem is this: rendering, AI, and physics tend to process faster on a GPU-like architecture compared to a CPU-like one, because they are naturally parallel problems. Trying to solve these problems on a serial architecture will reduce performance, assuming no bottleneck is present. Meanwhile, GPU performance, while currently maxed out, is increasing faster then CPU performance. So you start running into theoretical questions like "If we get 20% more GPU power next generation, does my GPU bottleneck go away?" or "Will I end up introducing a CPU bottlenck instead?".
For a general purpose PC, there is no right answer, because on some configurations, an approach like Crysis 3 WILL CPU bottleneck, where other titles generally won't. But with PCU's gaining maybe 10% performance per generation, and GPU's gaining at least twice that, if you had to be stuck with a performance bottleneck, which component would you rather it be? Nevermind, again, the case the CPU decides to do something else while your program is running. [Remember how many OTHER processes run in the backround, any one which can pre-empt you.]
This is relevent when discussing OpenCL, since OpenCL is basically offloading processing to the GPU from the CPU. For example, TressFX wouldn't be possible on CPU processing alone [too process heavy], but can easily take off 25% of your FPS [GPU overworked]. Hence, again, why I feel Agiea had the right idea with their PPU: A dedicated unit to handle advanced physics processing. I honestly think the end result is going to be a dedicated co-processor independent of the GPU. I honestly wouldn't be shocked if we ended up with something looking like HSA + Discrete, with the APU unit handling physics/AI, the dedicated GPU handling rendering, and the CPU driving the program. This would be the easiest way to work around the performance bottlenecks of the GPU, in my opinion.
Facebook
Twitter
Instagram