B/C aside, is there any reason that Sony couldn't use something derived from the Power 7 series, complete with OoOE and all the other bells and whistles?
How useful is OoOE in a console where programmer can fine tune their code ?
B/C aside, is there any reason that Sony couldn't use something derived from the Power 7 series, complete with OoOE and all the other bells and whistles?
B/C aside, they could use anything they like.
Xenon has ~165M transistors. Dualcore I7 has ~500M. For the budget of one Xenon you could get a bit more than half an I7 core. Cell had ~241MFrom what I understand power7 has a metric ton of extra hardware for stuff that consoles most likely will never need like hardware BCD and all sorts of encryption things.
The Power7 core itself (including 256kB L2) is pretty tiny. It's all the bells and whistles that make it huge (SMP linkage and eDRAM). Just look at the die photo.
Depends highly on how good the compiler is. If it's good enough that devs don't have to go too low-level for every bit of code then in-order CPU works just fine.
Definitely. I've never understood why people suggest Power7 when it's a server processor. Well, I guess it's a higher number than other Power cores, so must be better.Right. So maybe the next console CPUs won't look anything like Power7 then.
There's nothing IOE can do that OOOE can't. OOOE is a developer aid. Developers can throw code at it, and if it's fast enough, great. Job done. Only if it isn't would they then need to get down into low-level optimisation. IOE forces low-level optimisation from the outside, meaning you either need very good coders, or you get slow code. OOOE will fit in better with big developers with a mix of abilities, allowing junior programmers to churn out functional, if not pretty, code that the processor does a reasonable job of running, with critical functions given over to the senior programmers to write. Given the complexity of modern development, a console that can offer cheaper, easier development is going to be attractive.If you have to wait for something from memory won't it always be faster though? I know there are lots of cases where you can avoid doing this, but if you want to be able to branch and then perform a series of operations based on parts of a large data set then won't it always have a big payoff?
I've been wondering how high can one actually clock those newer ARMs. I know the A8 in my N900 has been OC'd from 600 to 1700MHz. With decent cooling I don't think it's out of question to see ARMs at well over 3GHz.Well presumably nothing from Arm, as I don't think they'll have anything with performance high enough (although maybe the A15?), and I doubt Sony want to be tied to Intel.
OoO doesn't help that much with it I think. Sure, you can probably fill some idle time when you are waiting behind caches but if you already have to make a fetch from RAM you probably won't have enough work to fill hundreds of cycles. The fetches from caches can probably be predicted by compiler and I think it's possible to make a system that when you need to get something from RAM you switch over to other SMT thread.If you have to wait for something from memory won't it always be faster though?
Combine it with SGX's scalability,
It's true that not many games use 4xMSAA for rendering visible graphics, but free 4xMSAA is a godsend for filterable shadow mapping algorithms (variance shadow maps, exponential shadow maps, EVSM, etc).That is assuming games would actually use 4xMSAA when emulated instead of using some smarter and far more efficient AA algorithm
What about GPU candidate for PS4. As much as I like to see SGX in there, I want to know how good is SGX at texturing and shading ? I am also expecting displacement maps and tesselation for next gen, how's SGX at those ?
I can't find any article that give the run down on SGX shader processor, All I know is it uses 32 bit internal colour precision, whether it uses scalar or vector processor, I don't know. Also to me SGX even in the MP16 configuration won't even rival AMD R700 that's rumoured to be in Wii2.
Is Series 6 going to be any better ?
It's true that not many games use 4xMSAA for rendering visible graphics, but free 4xMSAA is a godsend for filterable shadow mapping algorithms (variance shadow maps, exponential shadow maps, EVSM, etc).
For example, on an average frame we render four to five 512x512 shadowmaps using 4xMSAA. 512x512 with 4xMSAA uses bandwidth equal to 2048x2048 render target. With EDRAM, the system can provide that bandwidth. The AA is resolved by the EDRAM, so the shadowmap rendering and resolving uses exactly the same bandwidth as 512x512 without antialiasing. With antialiasing you do not need to blur the shadowmap (save lots of cycles there), and you get better quality (subsample precision "blur" helps).