I have seen several posts claiming that switching to an AMD GPU would eliminate backwards compatibility, but I don't see why this would be the case for well engineered software ...

For the most part, game engines will perform calls to the GPU through a standard graphics API that acts as a hardware abstraction layer; and in the case of Sony and Nintendo this API will most likely be OpenGL. All special features of the graphics cards are accessed through extensions to the standard API. Any distinct features of the PS3 GPU could easily be emulated on the driver of an AMD GPU by using a similar feature on that GPU or on the CPU.

This is the reason why OpenGL was invented, and is the reason why all of your games work on your PC when you decide to upgrade your graphics card.

Huh? The rsx is a 100% NVidia GeForce7800 chip. Sony paid NVidia $20mio for the changes required for the PS3 (replacing the dram interface to XDR drams, and removing the unneeded video circuitry) and to get a new GPU chip out in time (after their own graphic solution fell through).

I heard it was partially Sony's creation. So it was probally bad information.

Consoles are not made to be upgraded so some hardware level coding exhists in the game engines. We seen this with the Xbox/360 BC. Where the games that where not able to be played where acredited to Microsoft no longer being able to use nVidia's propritary code that Microsoft was unwilling to pay for the use of.

In PC yes almost all of the graphics coding is done in the API, but there are cases where games will be optimized for one cardset over another. When this happens there are two different "modules" present one that uses the API, and one that uses code specific for the card set. (The card manufacture usally funds moves like this.)

No, the reason why the XBox 360 had difficulty maintaining backwards compatibility are (primarily) because they switched their CPU architecture; and the instruction set of their new Power based CPU is completely different from the instruction set of their previous Intel based CPU. While you can perform instruction translation to make software run on a different architecture it is very computationally expensive and you run into compatibility issues; and the only way to ensure compatibility is to truly emulate the other system which would be even more computationally expensive.

With the migration from the PS2 to the PS3 there is a bit more of an impact by the change in GPU architecture primarily because the PS2 did not have OpenGL support "out of the box", so developers often produced their own library and (since there was no driver and hardware abstraction layer) there is no way to make their games take advantage of the native OpenGL support on the PS3.

Edit: it is possible that there were some features of the GPU that could not be supported by the XBox 360, but I suspect that would be much more of a patent/licensing issue than a technical issue.

As far as I know GPU emulation is easier than CPU emulation as the range of functions each component can perform is very limited with simple instructions. Especially as the RSX is a pre unified shader GPU, A modern GPGPU with unified shaders should be able to emulate any function on the GPU with a simple abstraction for most games (99% there will always be some game that does something really off the wall that won't work without the exact hardware) the only way to get 100% is to use the exact same hardware.

It is what they used for PS1 BC on the PS2 despite the GPUs being totally different and there is a list of PS1 games that didn't work http://en.wikipedia.org/wiki/List_of_PlayStation_games_incompatible_with_PlayStation_2, but most games work perfectly. Now modern GPUs are far more complex so there will probably be more games that won't work if they go this route next gen but the only alternative is putting a full RSX in the PS4 as Nvidia is at least 2 GPU architectures beyond the RSX anyway so they would have to use the same abstraction on a NVIDA GPU anyway.

Now the real problem is the CELL as there is a 0% chance of emulating that in the next 15 years so if they want BC they will need to use some form of CELL in the PS4.

P.S. One of the main reasons that PS2 GPU emulation couldn't be done on the PS3 was that the "Graphics Synthesizer" had embedded EDRAM frame-buffer (and a bunch of really unique memory management quirks) that had far lower latency and higher bandwidth than the VRAM used in the PS3 so there was no way of emulating the framebuffer accurately in software, PC emulators use a lot of tricks and buffers to get PS2 games to work but the emulation is nowhere near perfect and really wouldn't be worth it on the PS3 as it requires a lot of per game optimisations and and has a much lower compatibility rate, the PS3 uses a very standard GPU in comparison. There is a blog post about it for PCSX2 but I won't link that here for obvious reasons.

On the topic of CPU emulation ...

In the not too distant future I expect to see console manufacturers move towards having developers target a "virtual machine" rather than develop for the hardware directly. With how good JIT compilers are getting, you can still get a highly optimized program without being directly tied to specific hardware. If this was done well the vast majority of games would be "forward compatible" without losing a significant percentage of their performance.

doing that would lose all the advantages of running on dedicated hardware and the optimisations that makes possible. You would basically be making a PC game at that point (they can be optimised but they will never be able to get the level of optimisation of games designed "direct to the metal) but with slightly higher overheads (and you know how much devs complain about API overheads on PC) you won't see it next gen I don't think we will be at the point where hardware far outstrips the games capability to utilize it which is where you need to be for virtual machines to make sense, that or a totally hardware agnostic future where you can buy one game for all platforms (which I don't think the hardware manufacturers want as that would mean they couldn't charge as much royalties). Virtual mchine bassed games could make sense on PC tho as it would prevent issues with conflicts but even there the extra overheads (no matter how slight) make that prohibitive for AAA games. But for lower end games that want to be platform agnostic Java/HTML5 virtual machine makes a lot of sense as you can make one game that will run on anything, even in a browser like Bastion etc.

/Nerd rant

The primary considerations for producing high performance code is using the correct data-structures and algorithms, not on hand-optimization of byte-code that is better handled by a compiler. Even then, the 0.1% of code that you would (potentially) want to write in assembly to increase performance can be (mostly) written by the console manufacturer and provided as library to your VM.

Beyond this, people have been benchmarking C++ vs Java for nearly a decade with results that demonstrate that JIT compilation of Java byte code into machine-code produces similar (overall) results to compiling C++ code into machine-code; with each language having its own advantages in a handful of areas.

Google has already taken this approach with Android, and I don't think many people would say there has been noticeable performance problems on those devices because their games are java based ...

With that said, I'm not saying that this upcomming generation will move towards a virtual machine approach but I'm certain the following generation will ...

Wasnt AMD working with Microsoft aswell?