Waccoon wrote:
1) On the Amiga, the CPU and chipset have to share memory. Yes, they have their own address spaces, but they don't have "dedicated" memory. Modern PCs use memory controllers to keep the main and sub processors from conflicting with each other or wasting effeciency, or have their own local memory. The Amiga isn't even close to what is being done years ago, let alone today.
Some PCs have dedicated memory for co-processors, not all. Hence the existence of UMA and other schemes (like integrated gfx controllers that have to be allocated RAM in the BIOS). The Amiga didn't use dedicated memory because there was no point in it - the 68000 could arbitrate with the other chips quite happily; it was only when the faster CPUs like the 68020 came along that Fast RAM was needed. Incidentally, the Xbox 360 I believe uses shared memory same as the Amiga...
2) The Amiga did not have sufficient abstration layers to use the custom chips effectively. Hence, the sheer mass of games that won't run on AGA. The reason why multi-processor architecture works is because of the software layers that can shift responsibilities between different architectures. Commodore wasn't even close to making their own DirectX.
The abstraction layers had nothing to do with the lack of running on AGA - it was hardware programmers who didn't obey guidelines that caused that. That's why some games from 1985 run perfectly while some from 1991 don't run at all on AGA. The programs that were written cleanly and obeying the CBM guidelines would continue to work. Of course some programmers
deliberately went outside the guidelines to get more speed, but again that's nothing to do with the (lack of a) HAL.
CBM
did have a primitive form of DirectX - or at least what was needed, i.e. the standard OS calls for blitting etc. which used the hardware. It wasn't as complex as DirectX because it didn't need to be, but it did the same thing (at least as far as 2D, as 3D was of course impratical).
3) Dedicated hardware is expensive, and if you don't use it, it goes to waste. The reason why AMD was so keen on purchasing ATI is because, ironicly, the CPU and the GPU are capable of very many similar tasks. That means consolidation of the architecture improves efficiency and performance, at least for the low-end. This is also why the physics and AI coprocessors will flop horribly. Of course, consolidation isn't a good idea in the high-end -- Sony's Cell processor is perfect proof of that.
I'm sure people said the same thing the first time someone suggested putting a 3D unit onto a graphics card (which originally were little more than frame buffers with rectangle-drawing 'acceleration').
I'm playing devil's advocate here - I don't think that physics and AI chips would catch on, at least in the short term - but we shouldn't discount them. Weirder things have happened. It only takes nVidia or AMD to incorporate an AI chip onto a graphics card and call it a "gaming card" and all of a sudden it's the norm.
I'm not sold on this multi-processor idea. Unless all the hardware is perfectly synced, you're going to have a lot of waste. This is especially true if, for example, you want specific ports that aren't built into the motherboard. The whole point of a motherboard is to offer the basics and accept daughtercards that do the specialized stuff. This multiprocessor idea is more along the idea of a game console than a PC. Flexibility is what PCs are all about.
I think it's likely in the long run, actually, simply because people always want faster and faster games particularly, but CPUs are struggling to keep up as we get to the limits of the technology used in them. Look at how parallelisation has taken over the CPU world - AMD and Intel have both realised there's no point in pumping the speed up as it's impractical, so they're having to double or quadruple the cores in their CPUs to keep up with Moore's law as they're expected to do. It stands to reason that eventually the CPU manufacturers will start thinking more and more "out of the box" of how to get higher speeds in benchmarks.
