Rumors have it that both the PlayStation 4 and Xbox 720 that should launch around the end of this year will use eight AMD Jaguar cores.  By modern standards, that means rather poor single-threaded performance.  But eight cores means that in well-threaded programs, you get CPU performance somewhat comparable to an FX-4300 or two cores of a Core i7-3770K.  That's not a top-end gaming system by any stretch, but it's decently capable, and console budgets really don't allow top-end gaming systems.

There are sound reasons why Jaguar cores should be attractive to both Sony and Microsoft.  For starters, they're very small, so even eight of them doesn't take all that much die space.  They're also very low power, so eight Jaguar cores at full load might still only be 15-20 W of power consumption.  The above comparables of an FX-4300 or half of a Core i7-3770K will use vastly more power than that to give the same performance.  Low power matters when you're trying to fit a console form factor.  They're also made by AMD, which is one of the two vendors that can offer modern, high performance graphics (with Nvidia being the other).  That matters if you want to integrate a CPU and GPU into a single die, which saves greatly on cost.

Less well-known is that Jaguar cores are designed to be relatively easy to move to a different process node.  Most CPU chips never try to move exactly the same chip to a different process node, as if you're going to have to redo the chip anyway, you probably should make some changes to try to increase performance.  But consoles do need to move to new process nodes multiple times to save on production cost, and have a fixed performance target with no benefits to adding more when you do die shrinks.

But then comes the huge catch:  poor single-threaded performance.  The general rule is that more cores clocked lower wins if your workload scales well to many cores, but fewer cores clocked higher wins if you can't use the extra cores.  Games aren't that hard to scale well to use many CPU cores.  But a lot of games just don't do it, for a variety of reasons.  Will the necessity of scaling well to more cores in order to run well on the new consoles finally push more game designers to implement threading properly?  Some games already do, but some don't.

A skeptic might argue that we've gone down this road before with the Cell in the PlayStation 3, and that didn't work out very well.  But from the GFLOPS numbers claimed for the Cell chip and its claimed applications, it sure looks to me like that's only high performance in special cases, such as SIMD.  That's not general-purpose enough to allow games to fully exploit the power available.  While games can scale well to many CPU cores, they do need for different CPU cores to be able to do whatever they want without any dependence on what the other CPU cores are doing at the time, and without a ton of latency if you have to do things out of order.  I don't know exactly what Cell can do, but if it could do everything needed for games, we'd have been using them in desktops and laptops a long time ago.

Originally posted by Quizzical  I don't know exactly what Cell can do, but if it could do everything needed for games, we'd have been using them in desktops and laptops a long time ago.

i know the cell was useful for making cheap supercomputers - but no idea about gaming

How the PS3 Helped Build the World's Fastest Supercomputer

http://www.popularmechanics.com/technology/engineering/4267979

US Air Force connects 1,760 PlayStation 3's to build supercomputer

http://phys.org/news/2010-12-air-playstation-3s-supercomputer.html

The 360 Xenon was already a triple core, and the PS3 Cell CPU is technically a 9-core CPU.

So no, it won't do anything for multithreading if the next gen has 8 cores.

Nothing is official yet Mo.

Xbox next has most recently been rumored to have a "custom D3D11.1 gfx card running at 800 mhz."

And we all know that optimization is a huge factor for the console as the engine/code can be more finely tuned to the specifics of the hardware, instead of having to be scalable to a wide range of hardware like the PC version.

Latest rumor:

• _{x64 Architecture}
• _{8 CPU cores running at 1.6 gigahertz (GHz)}
• _{each CPU thread has its own 32 KB L1 instruction cache and 32 KB L1 data cache}
• _{each module of four CPU cores has a 2 MB L2 cache resulting in a total of 4 MB of L2 cache}
• _{each core has one fully independent hardware thread with no shared execution resources}
• _{each hardware thread can issue two instructions per clock}

• _{custom D3D11.1 class 800-MHz graphics processor}
• _{12 shader cores providing a total of 768 threads}
• _{each thread can perform one scalar multiplication and addition operation (MADD) per clock cycle}
• _{at peak performance, the GPU can effectively issue 1.2 trillion floating-point operations per second}

• _{8 gigabyte (GB) of RAM DDR3 (68 GB/s)}
• _{32 MB of fast embedded SRAM (ESRAM) (102 GB/s)}
• _{from the GPU’s perspective the bandwidths of system memory and ESRAM are parallel providing combined peak bandwidth of 170 GB/sec.}
• _{Hard drive is always present}
• _{50 GB 6x Blu-ray Disc drive}

• _{Gigabit Ethernet Wi-Fi}
• _{Wi-Fi Direct}

_{Hardware accelerators:}
 

• _{Move engines}
• _{Image, video, and audio codecs}
• _{Kinect multichannel echo cancellation (MEC) hardware}
• _{Cryptography engines for encryption and decryption, and hashing}

Originally posted by Ridelynn

The 360 Xenon was already a triple core, and the PS3 Cell CPU is technically a 9-core CPU.

So no, it won't do anything for multithreading if the next gen has 8 cores.

There's a big difference between three cores and eight, especially when it's eight slow cores.

I don't know the details of the Cell architecture, but I have the impression that it's much harder to properly thread code for than a normal multi-core CPU as you'd find with x86 or ARM or whatever.

For an example of why this could be, let's consider GPU chips.  A Radeon HD 7970 has 2048 shaders, but they can't do 2048 completely independent things.  Rather, the architecture is very SIMD-heavy, as are all other recent graphics architectures.  Shaders are broken up into groups, and every shader in the same group can execute the same instruction at the same time, but they can't execute different instructions at the same time.  For example, they could all do a 32-bit floating point addition at the same time, but you can't have one add while another multiplies, or even have one do floating point addition while another does integer addition.

For video cards, this works fine.  The way that OpenGL (and probably DirectX) is set up is that you write a program that takes in arbitrary vertex data and processes it in a particular way.  Every vertex in your model runs through exactly the same program, but merely starts with different data at the start.  So you take your starting values, multiply by this, add that, and so forth.  Later programmable pipeline stages take in data as output from a previous stage, but they still have a bunch of data that they run through exactly the same program.  When your models have a bunch of vertices, a bunch of triangles, a bunch of pixels, and so forth, and your program uses little to no branching (if/else) you can exploit this pretty well.

But to try to cram CPU computations for games into something so restrictive would be much harder.  You're probably going to need pretty extensive branching, so you don't really get that many easy cases where you have a long string of instructions that get executed in the same order a bunch of times in a row.  GLSL doesn't even offer recursion, switch statements, or multidimensional arrays, because the situations where they would be useful for CPU code will completely kill your performance if you try to run them on a GPU.

The easy way to thread CPU computations for games on a typical desktop processor is with a producer-consumer queue, where different threads may execute much of the same code, but due to branching, different cores will tend to be in different places in the code.  For a typical desktop processor, you don't lose any performance if different cores need to execute different instructions at the same time.  Can Cell do that?  If not, then it's not at all similar to an 8-core processor that is easy to thread for games.  And if it isn't crippled in any way as compared to "normal" multi-core processors, then I'd question why it didn't get much broader use.

Originally posted by ShakyMo
Well they ain't going to push graphics much.

The xbox has an entry level gaming card, a 7770. The ps4 has something like a 7850 / 7870 so the ps4 should at least be putting all its games out in 1080p but its still behind current highish end pcs.

The xbox specs are really weak, not much different to the Wii u. I expect Microsoft to be going for a more casual market and doing a load of stuff with kinex. I think we will see quite a few games that are ps4 / pc only.

Rumors put the Xbox 720 specs way ahead of the Wii U.  On the CPU side, it's eight cores versus three, and the three cores are awfully slow, too.  I don't know how many shaders the GPU in the Wii U has, but the Xbox 720 should have several times the memory bandwidth of the Wii U.  That would certainly let it feed a much more powerful GPU.  While I don't know what GPU the Wii U has, my guess is that it's a lot closer to a Radeon HD 6450 than a 7770.

Originally posted by BadSpock

Latest rumor:

• _{x64 Architecture}
• _{8 CPU cores running at 1.6 gigahertz (GHz)}
• _{each CPU thread has its own 32 KB L1 instruction cache and 32 KB L1 data cache}
• _{each module of four CPU cores has a 2 MB L2 cache resulting in a total of 4 MB of L2 cache}
• _{each core has one fully independent hardware thread with no shared execution resources}
• _{each hardware thread can issue two instructions per clock}

_GPU:

• _{custom D3D11.1 class 800-MHz graphics processor}
• _{12 shader cores providing a total of 768 threads}
• _{each thread can perform one scalar multiplication and addition operation (MADD) per clock cycle}
• _{at peak performance, the GPU can effectively issue 1.2 trillion floating-point operations per second}

Or you could just say 8 Jaguar cores at 1.6 GHz and 12 GCN CUs at 800 MHz, which is what those specs would basically have to mean.  Well, the GPU could be some next generation derivative architecture of GCN.

AMD has said that by the end of this year, they expect their embedded semi-custom APUs to account for 20% of their revenue--which would come to over $1 billion annually.  It's hard to imagine what that could be other than consoles.  Nothing besides AMD Jaguar cores fits the CPU description, and nothing besides AMD GCN fits the GPU description.

Originally posted by Quizzical

Originally posted by BadSpock

Latest rumor:

• _{x64 Architecture}
• _{8 CPU cores running at 1.6 gigahertz (GHz)}
• _{each CPU thread has its own 32 KB L1 instruction cache and 32 KB L1 data cache}
• _{each module of four CPU cores has a 2 MB L2 cache resulting in a total of 4 MB of L2 cache}
• _{each core has one fully independent hardware thread with no shared execution resources}
• _{each hardware thread can issue two instructions per clock}

_GPU:

• _{custom D3D11.1 class 800-MHz graphics processor}
• _{12 shader cores providing a total of 768 threads}
• _{each thread can perform one scalar multiplication and addition operation (MADD) per clock cycle}
• _{at peak performance, the GPU can effectively issue 1.2 trillion floating-point operations per second}

Or you could just say 8 Jaguar cores at 1.6 GHz and 12 GCN CUs at 800 MHz, which is what those specs would basically have to mean.  Well, the GPU could be some next generation derivative architecture of GCN.

AMD has said that by the end of this year, they expect their embedded semi-custom APUs to account for 20% of their revenue--which would come to over $1 billion annually.  It's hard to imagine what that could be other than consoles.  Nothing besides AMD Jaguar cores fits the CPU description, and nothing besides AMD GCN fits the GPU description.

I am so thankful for you Quiz :)

So based on said rumor and description, what kind of power can we expect?

Compare the "8 Jaguar cores at 1.6 GHz and 12 GCN CUs at 800 MHz" to a desktop equivalent for us?

An AMD FX-8350 severely underclocked to 1.6 GHz together with a Radeon HD 7770 at stock speeds would be in the right ballpark.

The 7770 has 10 GCN CUs at 1 GHz, which means about 4% more GPU performance (at least as far as shaders and TMUs are concerned) than the rumored Xbox 720, or whatever Microsoft will call it.  The memory system will be very different, and the ROPs could also be rather different, since those aren't tied to how many shaders you have.

As for the CPU, you're looking at eight slow cores.  Jaguar cores are actually the successor to Bobcat cores in AMD Z-, C-, and E- series APUs, but will be substantially faster on a per clock cycle basis.  There aren't any chips with more than two Bobcat cores, which is why I had to compare it to Piledriver cores that are meant to clock much higher.  The reason to clock the CPU cores around 1.6 GHz is that that's about what they can handle with good yields.

It sounds like the initial top bin of Kabini (which will use Jaguar cores) will be a quad core clocked around 1.7 GHz.  Consoles have to take lower specs than you'd use on the top bin for a desktop or laptop part, as consoles can't have lower bins.  For a desktop or laptop chip, if you set your top bin to be something that only 1/3 of your chips can meet, then you can still sell most of the other chips as lower bins (clocked lower, some pieces disabled, etc.).  For a console, you have one bin, and any chips that can't meet the specs of that one bin get tossed in the garbage, so you make sure that most of your chips can meet that one bin.

Originally posted by DeniZg
I wonder how does MS plan to implement backwards compatibility, with such discrepancy between old and new CPU architecture (old 3x3,20 Mhz cores vs. new 8x1,6Mhz cores)?

Maybe they don't.  Even if they wanted to, it's not clear how even faster x86 cores would be able to handle games written for PowerPC.

PS4 announcement on February 20th?

Originally posted by DeniZg
I wonder how does MS plan to implement backwards compatibility, with such discrepancy between old and new CPU architecture (old 3x3,20 Mhz cores vs. new 8x1,6Mhz cores)?

Im in the same boat with this.  I wasnt too pleased that backwards compatiability wasnt that great for the 360.  It really took the developers of the games to patch it for the 360.  With a lot of game developers going under, and a library of games on my shelf.  Im worried about this.

Code gets tighter and more efficient when the hardware presents more limitations. If the hardware does more work or presents less limitations, the code is not as optimized.

Examples:

On old versions of DOS, the executable (.COM file) needed to fit within 64k of space. As programs advanced, more concern was put into optimizing the code to keep the binary within that window. When memory allowed for larger executables (.EXE file), programs that did exactly the same work surpassed that size barrier.

Compilers and Interpreters are a great example to use.

Write a simple Hello World program in ASM and it's probably about 20 bytes.

Write it in Borland C++ 3.1 and it's about 1k

Write it in Turbo Pascal and it's about 4k.

Move forward a few years and you've VB3, a language that can only exist with the faster 386 and up processors and the 1.44M diskettes because not only is it interpreted (measurably slower than a compiled program at the time) but it also requires a 300k library just to make the same Hello World program the others made. If floppies were still 360k or 720k and processors chugging along at 4-12Mhz, VB3 would either have not been as successful or it would have come out the gate a far more optimized language.

(sorry for the outdated references but my coding days ended 15 years ago )

Software will always be less optimized and more bloated when it has the opportunity to. Most of the time it only becomes more efficient is when hardware limitations need to be overcome.

Originally posted by desdecardo

Originally posted by DeniZg
I wonder how does MS plan to implement backwards compatibility, with such discrepancy between old and new CPU architecture (old 3x3,20 Mhz cores vs. new 8x1,6Mhz cores)?

Im in the same boat with this.  I wasnt too pleased that backwards compatiability wasnt that great for the 360.  It really took the developers of the games to patch it for the 360.  With a lot of game developers going under, and a library of games on my shelf.  Im worried about this.

I'm not sure if they will be looking at backward compatability due to the fact they are introducing a system that will only allow the game you bought and played on your new console, to be locked to that console, thus not allowing the sale of pre owned games.

If they find a way around it, that would be amazing but also hard to do.

Hopefully they see sense and scrap this idea of locking the games into the console as it will kill off console gaming imo.

Think of all the old consoles with their own format.

Nintendo: NES / SNES / Nintendo 64
Sega: Sega Genesis (megadrive) / Sega CD / DREAMBOX
Atari: Atari Jaguar

Then those "mobile" divices.
Sega X
Gameboy
...
...
..

I doubt if the new consoles are incompatible, it will end as much of an issue as people make out.
I myself, bought a lot of classic snes games for the playstation - again - and there are always also the EMUs for old console games on PC :)

If incompatiblity means we will finally after 15 years of stagnation see some little revolution like back then going from 8bit to 16 / 32 bit and then the jump to polygons and CDs -

then we all benefit from it.

must admit to being more than a little puzzled, why would they choose to base the 'next gen' consoles on processors that are only capable of running at 1.6ghz, to me it just doesnt make sense, we're already seeing multicore processors for PC's running at 3.0+ ghz  and we're not even talking high end, but the mid range PC's as for Cores, 8 isnt really that awesome a number anymore, its already been exceeded.

It looks more like the 'power gap' between PC's and Consoles just gets wider and wider, when even a mid range PC is capable of far more than a console that hasnt even hit the streets yet

---

Originally posted by Quizzical

---

Originally posted by DeniZg I wonder how does MS plan to implement backwards compatibility, with such discrepancy between old and new CPU architecture (old 3x3,20 Mhz cores vs. new 8x1,6Mhz cores)?

---

Maybe they don't.  Even if they wanted to, it's not clear how even faster x86 cores would be able to handle games written for PowerPC.

---

Not that it applies directly to video games, but this isn't unheard of.

Rosetta

When Apple switched from PPC to Intel processors a few years ago, they kept support for all their PowerPC-based binaries via an emulator called Rosetta, that ran transparent in the background.

Now, I don't know how well a Xenon or Cell CPU compares to, say a G5/Power970 (aside from the fact that all 3 are PowerPC based), but for the most part the switch wasn't that bad. Intel had poorer FPU performance, and lacked some specialized instructions (AltiVec, mainly) that were on the PPC, but general code ran fairly well, usually within about a 50-25% margin, comparing a similarly clocked dual core G5 to a dual core Core Duo (not Core2). The wide margin due to the differences in FPU/Specialized instructions (which Apple had promoted widely during their PPC years, and put a lot of optimization for in their software). Note: this isn't comparing optimized x86 code to optimized PPC code, this is comparing PPC code running natively on a PPC to PPC code running emulated on a x86.

So, would that margin be "good enough" for games? Some, but not all. That, and the fact that the bulk of the game time is spent on the video card - and the video architecture isn't changing that much, just the CPU portion, so it wouldn't be outside the realm of possibility to see an emulator for the Gen 3 consoles, but I wouldn't count on it.

I wouldn't be surprised if we see the more recent model that is leaned on by Nintendo and Sony (mainly for their legacy titles), where there is no or limited blanket backwards compatibility, but we see those titles re-released as compatible downloads (and yes, you'd have to pay for them all over again...), which are just the ROM wrapped up in an optimized emulator for that title.