AMD Fusion To Add To x86 ISA

Giants2.0 writes "Ars Technica has a brief article detailing some of the prospects of AMD's attempt to fuse the CPU and GPU, including the fact that AMD's Fusion will modify the x86 ISA. From the article, 'To support CPU/GPU integration at either level of complexity (i.e. the modular core level or something deeper), AMD has already stated that they'll need to add a graphics-specific extension to the x86 ISA. Indeed, a future GPU-oriented ISA extension may form part of the reason for the company's recently announced "close to metal"^TM (CTM) initiative.'"

Comments

Am I the only one?

[man_of_mr_e]

Am I the only that thinks this is a bad idea? Either I change video cards more often than CPU's or CPU's more than graphics cards, but in either case I seldom want to upgrade both at the same time. Although I suppose I wouldn't mind a better GPU "for free" with my CPU, I suspect it won't be "for free".

Re:Am I the only one?

[Rosco P. Coltrane]

Am I the only that thinks this is a bad idea? Either I change video cards more often than CPU's or CPU's more than graphics cards, but in either case I seldom want to upgrade both at the same time. Although I suppose I wouldn't mind a better GPU "for free" with my CPU, I suspect it won't be "for free".

Look at it this way: nowadays you can get a computer with a video "card" onboard the motherboard, but nothing prevents you from disabling it and installing a separate video card. Most likely, that's what's gonna happen in this case. But remember, one of the advantage of merging the cpu and gpu is to get around the bus bottleneck, so presumable an embedded gpu may well blow any separate video card out of the water in terms of performance. Unless of course this is just a marketting stunt, or a consumer lock-in scheme, which is just as likely...

Re:Am I the only one?

[cnettel]

On the other hand, the real payoff of low latency won't surface if every operation means going through a driver, which only then realizes "oh, I have a single instruction for this thing, let's head back to the caller". This means that game writers will either still need to batch up complex operations, that the driver will then translate into batches of suitable instructions, or that we'll see games/applications with radically different codepaths. Any attempt to benefit optimally from the integrated approach will perform badly on a separate card, while code tuned to a separate card won't come close to harnessing the good points of an underpowered, but lower latency, local graphics implementation.

It's almost like they would add L3 in a non-transparent manner, that is, expecting the developers to write the code moving suitable data into the cache and addressing that data in a radically different manner, while still also supporting the normal style of memory access, where you of course need to care about the cache, but not so explicitly. (The Cell's explicit local RAM for each unit, and the whole design of that beast, comes to mind. At least ALL PS3s will have one, but the expected target market for Fusion-only adaptations is much less clear cut.)

And, yeah, this is quite like the situation almost ten years ago, when 3D cards were hot and new. Writing a pipeline to feed those cards was quite different from rolling your own hacked-up software rendered. (And with T&L and shaders, the move has been even greater.)

But maybe then I'm just speculating a bit too much here. It would make sense that AMD is designing these instructions to fit into the existing driver model (or at least the DX10 one), so that you can get pretty good performance by just doing the relevant translation there.

Re:Am I the only one?

[mrchaotica]

Shouldn't this kind of thing be the compiler or library writers' problem, not the application developers'?

Re:Am I the only one?

[gripen40k]

From what I understand I think the parent is right. If you use OpenGL, you don't worry about pipelining or however else the computer actually 'makes' the graphics, you just code it. Buuuutt.... I guess you would need to compile two versions of the same thing and put it on the same game disk, or figure out some kind of neat system so that translations are done in real time with hardware (much faster than the soft approach).

Re:Am I the only one?

[Sparohok]

The history of computer architecture is a ceaseless march toward higher integration and higher generality. That is, what was once special purpose hardware in a seperate unit is now implemented in firmware as part of a more flexible, general purpose processor.

This march is littered with those standing by the wayside saying things like, "Who needs floating point in the CPU? Leave it on a seperate chip!" or "I want to be able to upgrade my CPU without buying a new memory controller!" or "If you integrate sound on the motherboard, I'll just have to buy a seperate sound card."

So, while I'm sure you're not the only one who thinks GPU integration is a bad idea, that doesn't mean it is a bad idea.

Re:Am I the only one?

[Alien Being]

"Buuuutt.... I guess you would need to compile two versions of the same thing and put it on the same game disk, or figure out some kind of neat system so that translations are done in real time with hardware (much faster than the soft approach)."

I don't think so. The application can be linked against a single graphics library. The GL just swaps some function pointers when special hardware is available.

Re:Am I the only one?

[rbanffy]

As added benefits:

- With a public and standard ISA, you will have Linux-compatible drivers shortly

- With a public and standard ISA, people will have a single standard to code against. Library support should be excellent.

- While your über-FPUs/vector accelerators/stream processors (what GPUs are made of) are not GPU-ing something, they can accelerate SSL, physics processing and any other vector-friendly activity you may have. Playing Flash content, maybe.

- GPUs are memory-hungry. The added memory bandwidth will benefit all software, not only graphics-intensive stuff.

- There is nothing that precludes you from using a stand-alone GPU, provided you have the drivers. But your CPU will have a couple high performance units that can give it a hand. Think asymmetric SLI.

We will see how well the idea performs by watching the Cell processor (a CPU with 8 "GPU"s attached) in the PS3. That's roughly the same idea.

In the meantime, I bet it will work just fine.

Re:Am I the only one?

[man_of_mr_e]

Gamers aren't the only ones driving the market. You'll want a fast dual core processor for Vista, for instance. Software will always expand to fill all available CPU Cycles. I just see software becoming more powerful, not just games. Thinks like more AI in real-world apps, star trek level stuff.

Re:Am I the only one?

[241comp]

How about the ability to have dual video cards within a laptop? The low-power on-cpu video driver for when you're just browsing the web or whatnot and the latest Nvidia/ATI pci-e power-hog for when you're gaming... think of the battery life you could have when reading your email at the airport without sacrificing the ability to play your favorite games at full res.

Re:Am I the only one?

[mrchaotica]

Maybe I'm just projecting, but what I think that you want, and many others out there want is simply a better bus, bridge, magic, glue or whatever you want to call it between the major parts of a computer.

Hmm... you might be right. But an equally important aspect is that I want a socketed GPU and graphics memory, so that it would be modular just like the CPU and system memory.

A combo CPU/GPU either only targets the very low end generic computer or a specialized graphics type of computer. With the failure of the other addons to computers, I don't see the advantage. Graphics simply don't matter in the server market.

You're thinking too small. Modern GPUs don't just do graphics; they are becoming able to do just about any kind of very-parallel computations.

For example, imagine a server of some kind that processes every packet it sends in the same way. Let's say it has 1000 connections, and that each one is handled by a separate thread. Now, imagine that the thread can somehow be implemented as a shader. Then, instead of processing 1 or 2 packets at a time (as on a single- or dual-core CPU), you can suddenly process (tens? hundreds?) of packets simultaneously! Even if the thing is clocked lower than a CPU, I'll betcha it'll still have better overall performance -- assuming you can make it work.

Personally, I think there are quite a few problems like this, that could be parallel even though they aren't usually implemented that way now. I think it's a matter of how most programmers are used to traditional CPUs, and so don't think in a parallel way. I'm actually banking on this becoming a big deal in the future, which is why I'm taking a bunch of graphics, systems and HPC classes (I'm a CS student). And it had better do so, because otherwise computers are going to stop getting faster -- the whole reason everybody's so focused on multi core systems now is that they've hit a wall wrt. the laws of physics.

Re:Am I the only one?

[jhfry]

I have made a similar argument, I want a FPGA on the HT bus. A Fully Programmable Gate Array would allow software developers to create hardware "programs" to accelerate their products. For example, Photoshop and Premiere could re-program the FPGA to accelerate processor intensive tasks. Codecs could be implemented on the chip for realtime encoding (for example http://www3.elphel.com/en/products is a camera that does OGG Theora in a FFPGA in realtime at 640x480x90fps). And game writers could optimize any part of their applications they wish. Sure FPGA's are not as fast as a non-programmable processor, but they are infinately more flexable, and if it's sitting on the HT bus with direct access to system RAM, you would see some amazing uses. Accelerated encryption/decryption, email filtering and virus detection, or any other process that is sequential in nature and done repeatedly.

How long until a physics extension?

[User 956]

'To support CPU/GPU integration at either level of complexity (i.e. the modular core level or something deeper), AMD has already stated that they'll need to add a graphics-specific extension to the x86 ISA.

x86 is a great multi-purpose, but the reason we're seeing greater and greater offload onto a GPU is because that's great at a specific task. So my question is, how long until we see widespread PPU (Physics processing unit) usage, and beyond that, a Physics extension to the x86 ISA? Or will we all just be computing on the grid at that point?

Re:How long until a physics extension?

[Wesley Felter]

So my question is, how long until we see widespread PPU (Physics processing unit) usage, and beyond that, a Physics extension to the x86 ISA?

Never, since it looks like physics can efficiently run on GPUs now.

Re:One unanswered question?

[zpapasmurf]

no, but SLI isn't economical either. it's not the most bang for the buck, its the most bang.... period

Re:One unanswered question?

[Anonymous Coward]

Can it run Linux? OK JUST KIDDING!

Why joke? It is an important question.

All the current nvidia and ati graphics cards require proprietary, closed-source drivers.
If the GPU is to be integrated into the CPU, either they will have to keep the new ISA a secret or we will finally start getting access to the information required to really write Free graphics drivers.

Advantages?

[Tainek]

A lot of people seem to be having issues working out why AMD is doing this

people are forgetting that they are not always the target market for computers (this isnt aimed at you if you upgrade one more than the other)

for example, what is easyer for your computer illiterate father to do, change one slot component, or install a graphics card , and a cpu.

it also allows for even smaller form computers

i will concede, that these gains are pretty small though, i cant see it being worth it

What happened...

[dduardo]

What happened to the RISC philosophy? Keep the hardware simple and let the compiler do the work.

No, lets create 1000 more instructions for graphics, 1000 for physics and 1000 more just for the heck of it.

Re:What happened...

[Guy Harris]

What the programmer sees may be CISC, but what happens inside is RISC.

The article is discussing what the programmer sees, i.e. the instruction set architecture.

it died back in the 90's

[RelliK]

I guess I should clarify. RISC "philosophy" lives on, but practicality has long been dead. Modern CPUs have RISC microcode with a x86 -> RISC translator in front. The translator adds a bit of overhead and uses up some silicone, but on the other hand CISC instructions are smaller, so you can fit more of them in a given amount of L1/L2 cache.

Re:it died back in the 90's

[serviscope_minor]

I guess I should clarify. RISC "philosophy" lives on, but practicality has long been dead. Modern CPUs have RISC microcode with a x86 -> RISC translator in front. The translator adds a bit of overhead and uses up some silicone, but on the other hand CISC instructions are smaller, so you can fit more of them in a given amount of L1/L2 cache.

You are just plain wrong on many counts.

RISC outsells CISC my a massive margin. Just look at the presence of PowerPC, MIPS and (the biggest of all) ARM in the embedded market. Comparing number of cores sold anually, RISC is the winner by a very wide margin.

Dead is a funny description for something which sells far more units.

Secondly, Intel keep the micro-ops in the L1 instruction cache (known as trace cache), so the CISC instruction set doesn't help there (it does for the L2 cache).

And thirdly, its silicon. Rubber processors don't exist yet.

Re:Is the real goal just bundling?

[Prof.Phreak]

I can imagine the real goal being DRM. With everything on the CPU, making some instructions priviledged, they can force any program that wants to manipulate (decode?) video at a ``fast'' rate to call the OS to perform the decoding---allowing the OS to ensure the video has valid signatures before it proceeds.

Sure folks would still be able to use libraries that run on the CPU, but if those are inefficient/slow compared to the specialized instructions... then who knows.

Just being paranoid...

Re:I like your solution

[mabinogi]

Why don't you ask AMD, as they've apparently already considered it, or they wouldn't be talking about putting both the CPU and the GPU in the same package.

Without knowing anything about it, it would seem that if CPU+GPU in the same package is possible, then CPU + GPU in two separate CPU sized packages would be possible.