Slashdot Mirror


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.'"

11 of 270 comments (clear)

  1. Am I the only one? by man_of_mr_e · · Score: 4, Insightful

    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".

    1. Re:Am I the only one? by cnettel · · Score: 4, Insightful
      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.

    2. Re:Am I the only one? by gripen40k · · Score: 4, Insightful

      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).

      --
      Har?
    3. Re:Am I the only one? by rbanffy · · Score: 4, Insightful

      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.

    4. Re:Am I the only one? by mrchaotica · · Score: 4, Insightful
      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.

      --

      "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

  2. How long until a physics extension? by User+956 · · Score: 4, Insightful

    '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?

    --
    The theory of relativity doesn't work right in Arkansas.
  3. Re:One unanswered question? by Anonymous Coward · · Score: 5, Insightful

    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.

  4. Advantages? by Tainek · · Score: 3, Insightful

    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

  5. What happened... by dduardo · · Score: 3, Insightful

    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.

    1. Re:What happened... by Guy+Harris · · Score: 3, Insightful
      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.

  6. Re:I like your solution by mabinogi · · Score: 4, Insightful

    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.

    --
    Advanced users are users too!