Though not the largest market for either AMD or Intel, high performance computing has become a technology battleground for the two chipmakers. In the past few years, multi-core Opteron processors, HyperTransport technology, and the open standard Torrenza platform have propelled AMD to prominence in the high-end space. But with the introduction of Intel's new Xeon offerings, the game has changed for AMD.

Now, with last year's acquisition of graphics-card maker ATI, AMD appears to be pursuing a rather different path than its rival. To get a sense of how this is going to play out in the HPC landscape, HPCwire talked to Phil Hester, AMD Chief Technology Officer, and Bob Drebin, Chief Technology Officer for the company's new Graphics Products Group, about their vision for high-end processing and how this fits into AMD's overall business strategy.

HPCwire: Can you characterize AMD's high performance computing strategy?

Hester: It's a layered strategy. The top layer is generally what we refer to as accelerated computing. What this is basically trying to recognize is that workloads are getting more diverse, and that applies to both the client and the server space. Below this top layer of accelerated computing, there are at least two other elements.

One of these is the idea of Torrenza and being able to build specialized accelerators. An example of that would be the work done with GPUs and stream computing. There's also work we're doing with companies who use FPGAs for specialized acceleration, whether that would be Java, vector processing or whatever. We're also working with our key OEM customers, like Cray, to help them build custom silicon solutions on our Torrenza platform.

The third layer is really around what we see happening at the processor level itself with regards to the Fusion [CPU-GPU hybrid] processors. For a lot of workloads, the historic idea of more and more homogeneous cores is not the right answer. The better answer is a mix of heterogeneous cores. The first example of that will be a Fusion processor that is primarily aimed at the client space, driven by the fact that, with the advent of Vista, most of the applications that will run on desktop and mobile systems are going to require 3-D graphics.

There's an analogy to this in the early days of the PC. With an 80286-based PC and an open socket next to it for the 80287 math coprocessor, maybe one percent of the people bought the coprocessor. In the 80386 generation, with the 80387 socket, maybe 10 or 20 percent of the people bought the coprocessor. After the introduction of Windows and other emerging applications, the 80486 processor integrated the FP coprocessor because at that point enough of the applications demanded floating point. The economics was such that the incremental die size increase to incorporate floating-point capabilities just made sense. We're kind of to that point now in the client space [with graphics functionality].

With that said, once you put a GPU on-chip, you will be able to exploit the capability of that device to solve more general-purpose problems. That means that over time, you want to expose new native mode user instruction extensions that leverage the capabilities of the GPU. The other thing that you start recognizing is that GPUs, as essentially large vector units, are optimized for parallel execution. If you look at the performance of CPUs versus GPUs for applications that are parallelizable, the GPU has 20 to 50 times better performance. By being able to exploit both sequential and parallel applications on a single chip, it's kind of a perfect map to Amdahl's Law.

Although the original Fusion processor will be targeted for the client space, we also believe that a lot of the characteristics, such as power efficiency and performance per watt, will likely be a good building block for large clusters. As I'm sure you know, some of these clusters are not necessarily limited by an organization's budget, but by the amount of power and cooling that they can get into their data center. So one important metric for us is performance per watt per dollar.

The flip side of that is because every one these client CPUs has this graphics function integrated in it, it will never be designed to be the world's highest performance floating point device or GPU. We still believe that in the desktop and client space, there will continue to be a need for GPUs just as we know them today. And likewise, GPUs are going to continue to evolve to do, for example, true IEEE math. So our stream computing initiatives are the beginning points of figuring out how the GPU itself needs to evolve to become a more generalized element of a high performance technical computing solutions.

HPCwire: How do you see Fusion processors evolving in relation to high performance computing?

Hester: Fusion is a general category of these heterogeneous processing units. Today, we've done enough work to know with high certainty what the implementation should look like in the client space. Part of the early work we're doing now (through the “Close to Metal” stream computing initiative) is to understand how to generalize the capabilities of the GPU and how it needs to evolve in order to best run these high performance technical computing workloads. The [result] of that work will be incorporated into what we do with future Fusion processors and discrete GPUs, both of which could be used as elements of HPC solutions.

Drebin: Now that ATI is a part of AMD, we are really looking at the total platform compute solution. You can be very chip-centric, but we want to make sure that AMD provides the best computing platform for diverse types of applications. Certainly on the graphics side, the types of processing and precision have gotten more sophisticated as the problems we're solving require it. What we see moving forward is that the class of problems that are going to be desired by GPUs for their classic markets are also going to be more and more HPC friendly. On the CPU side, we see these devices getting better at data parallel tasks, both through the instruction set and through the use of multi-core. During this time we want to make sure that we leverage the sequential processing strengths of the CPU and the data parallel strengths of the GPU. It may take the form of different architectures. For example, you might have separate GPU and CPU chips, where the GPU has its own memory subsystem, but there's a better coupling than there is today.

But long-term, as the properties of the two processors, in terms of the quality of their computations and their ability to work with arbitrary instructions, gets to a certain point, then true coprocessing starts to make sense. When we look at the future, we see a single chip that has the ability to leverage the strength and properties of both.

But even when we have the combined chips, you'll still want to have [standalone] GPUs that are better at HPC than they are today. I think you'll have both types of devices. It will not be a one-size-fits-all where everything maps into a single generic processor.

HPCwire: Do you see GPU supporting double-precision floating point?

Drebin: Yes. Looking forward, I think you will see that level of computation available on the GPU. But we don't want to prematurely give GPUs the same properties of the CPU. It would be the wrong time for the market. But we do see that as computations become more diverse, you will see the same level of precision.

HPCwire: What other ways do you see CPU-GPU integration evolving? For example, is it possible that multi-media/SIMD instruction support will be dropped from the CPU as CPU-GPU integration moves forward?

Hester: First, we're fully committed to 100 percent backward binary compatibility so we'd never drop instructions, because then you would potentially have applications that wouldn't run. The PC space guarantees that sort of backward compatibility.

But a variant of that is a very good question, which is: When you do have the GPU compute blocks on die, where do some of the multi-media instructions now execute? They don't necessarily have to use the same specialized silicon as before when you just had the CPU. So this goes back to our earlier point. Now that they're together, you are free to get the most optimum use of silicon, and I can well believe that some of the CPU silicon that is currently used to support multi-media instructions could be more efficiently done on the silicon devoted to the GPU function.

HPCwire: With that in mind, are you committed to supporting the GPU open software interface for future designs?

Drebin: Specifically what we do for our future chips I can't speak. But our motivation is that if you can directly control the GPU, you can get significantly better performance, and maybe more importantly, more consistent performance. Today, the GPU has a software layer –- a driver — that is in between the user and the hardware. So oftentimes when we come up with a software release to improve the performance of certain games or enhance certain properties, it can have a deleterious side effect on other applications that were tuned for a certain configuration. So we will be looking at the correct way to enable the kind of efficient computations that would be required by HPC markets. Whether that remains an ISA is really a function of how that evolves.

HPCwire: My understanding is that the ISA for GPUs is rather volatile from generation to generation. Is that a fair characterization? If so, what effect does this have on exposing the ISA to the programmer?

Drebin: Right. The ISA that exists today for the GPU certainly wasn't intended to be the long lasting instruction set. Each generation of graphics cards implements a dramatically different set of functionality, so the instruction set changes to match that new level of functionality. As we converge to the point of having the programming attributes that we associate with a CPU, I think the ISA will tend to stabilize.

Certainly the way you program it will have the consistency of a CPU ISA, but again as we approach that point, there are a number of different paths we can take. Do you have an instruction thread which is x86 plus GPU or do you maintain two separate ISAs?

HPCwire: How about homogeneous multi-core? Does your roadmap stop at eight cores for AMD's Opteron line?

Hester: There are classes of workloads in the SMP server space that scale pretty well with homogeneous cores. As we scale up, I'd say the biggest single problem is not the number of cores, but the balance of memory bandwidth with the compute capabilities of those cores. As I'm sure that you know, there's a growing disparity between the rate at which the parallel execution units can consume data and the memory technology to deliver it. So we don't think as much about the absolute number of cores as how we balance the system with the available memory technology and board-level interconnect technology. In many cases, you can actually get better system level performance for a given affordable die size, by devoting more of the die to the memory hierarchy as opposed to cores.

We really approach it from the standpoint of the market requirements to determine how we spend the silicon. The cores are certainly a visible piece, but at the system performance level, it's now my view that it's more important to deal with the memory hierarchy than anything else.

HPCwire: Your company seems to have a different overall strategy from Intel. Do you think this strategy has steered you away from a direct head-to-head competition with your rival?

Hester: I think generally the markets we participate in are largely the same. I think our philosophy of how we service our customers is very different. Some of this goes back to our Torrenza technology, which I talked about earlier. We actually like people attaching to the equivalent of our front-side bus. We want to build a healthy ecosystem around our CPUs and we aren't necessarily on the square that says we should own all the silicon in the system. So from my perspective, we're much more open about allowing people to innovate around the core chip.

The other thing that I would add is that one of the things that motivated the acquisition of ATI was the unhealthy and unnatural wars, if you will, that were going on between the CPU side and the GPU side. As Bob mentioned earlier, it's pretty clear to us that GPUs have been getting more general-purpose and CPUs have been adding more multi-media extensions.

The difficulty of doing a really good CPU and a really good GPU is extremely difficult. I'd argue that there are only two companies in the world that do a really good job at making an x86 processor and only two companies in the world that do a really good job at making GPUs. The idea that a CPU company could evolve into a GPU company, or that a GPU company could evolve into a CPU company is both high risk and long-term. And so this acquisition with ATI was a very strategic thought that says: As we look at these future workloads, there's a natural way that both the GPU and the CPU want to evolve at the system level. The best and most effective way to do that is within one company, which allows us to exploit the advantages of both CPU and GPU architectures. So from that standpoint, we now have the kind of differentiation that gives us the best of both worlds.