AMD Fusion System Architecture Detailed

Vigile writes "At the first AMD Fusion Developer Summit near Seattle this week, AMD revealed quite a bit of information about its next-generation GPU architecture and the eventual goals it has for the CPU/GPU combinations known as APUs. The company is finally moving away from a VLIW architecture and instead is integrating a vector+scalar design that allows for higher utilization of compute units and easier hardware scheduling. AMD laid out a 3-year plan to offer features like unified address space and fully coherent memory for the CPU and GPU that have the potential to dramatically alter current programming models. We will start seeing these features in GPUs released later in 2011."

Comments

I like the idea, but have concerns

[Sycraft-fu]

One concern of mine is simply performance with unified memory. The reason is that memory bandwidth is a big factor in 3D performance. The kind of math you have to do just needs a shitload of memory access. This is why GPUs have such insane memory configurations. They have massively wide controllers, special high performance ram (GDDR5 is based on DDR3, but higher performance) and so on. That's wonderful, but also expensive.

So it seems to me that you run in to a situation where either you are talking about needing to have much more expensive memory for a computer, possibly with additional constraints (at high speeds memory on a stick isn't feasible, electrical issues are such that you have to solder it to the board) or a system where your performance suffers because it is starved for memory bandwidth. Please remember that it would also have to share memory with the CPU.

Perhaps they've found a way to overcome this, but I'm skeptical.

I also worry this could lead to fragmentation of the market. What I mean is right now we have a pretty nice unified situation from a developer perspective. AMD and Intel have all kinds of cross licensing agreements with regards to instruction sets. So the instructions for one are the instructions for the other. While there are special cases, like 3DNow that only AMD does, or AVX which Intel has and AMD has yet to implement, by and large you have no problems supporting both with a very similar, or dead identical, codebase.

Likewise GPUs are unified from an app perspective. You talk to them with DirectX or OpenGL. The details of how AMD or nVidia do things aren't so important, that handled. You use one interface to talk to whatever card the user has. Not saying there can't be issues, but by and large it is the same deal.

Well this could change that. APUs might need a drastically different development structure. Ok fine, except AMD might be the only company that has them. Intel doesn't seem to be going down this road right now, and nVidia doesn't have a CPU division. So then as a developer you could have a problem where something that works well for traditional CPU/GPU doesn't work well, or maybe at all, for an APU.

That could lead to a choice of three situations, none that good:

1) You develop for traditional architectures. That's great for the majority of people, who are Intel owners (and people who own what is now current AMD stuff) but screws over this new, perhaps better, way of doing things.

2) You develop for the APU. That is nice for the people who have it but it screws over the mass market.

3) You develop two versions, one for each. Everyone is happy but your costs go way up from having more to maintain.

Of course even if everything goes APU it could be problematic if AMD and Intel have very different ways of doing things. Their cross licensing does not extend to this sort of thing, and I could see them deciding to try and fight it out.

So neat idea, but I'm not really sure it is a good one at this point.

Re:I like the idea, but have concerns

[YoopDaDum]

Unified memory is an implementation option, but not the only one. It definitely make sense when price matters more than performance. But for a higher end part you could have separate memories. Look at AMD multi-core CPUs, it's already NUMA (light) from the start: each core as a direct attached bank with minimum latency, and can access the other cores memory banks with a (small) additional latency. Extended here, the GPU could have a dedicated higher performance GDDR5 memory directly attached, but accessible from the CPU side (and similarly the GPU could access all the system memory). It's a NUMA extension for a hybrid architecture if you wish. It needs support from the OS/drivers to handle this in a transparent way, but NUMA is not new so existing know-how could be reused.

Regarding performance, on principle an integrated solution can do better by offering tighter integration and more efficient exchanges between CPU and GPU than going through a lower speed / higher latency external bus as for a discrete GPU. We shouldn't judge the principle by today implementations, as they target the low (bobcat based) and middle (llano) ends only, not yet the high end.
The con of integration is that you loose the flexibility of choosing CPU and GPU separately, and upgrading separately, but as others have pointed out most people do not care nor use this in practice.

As for fragmentation, it's the usual situation. You can hide the differences using things like OpenCL, but you'll sacrifice some performance initially compared to a targeted implementation. Most should target this when the tools become sufficiently mature. But if you want to extract all the juice you will have to be target dependent, and face this fragmentation indeed. Still, over time we can expect some convergence (the good ideas will become clearer, and be adopted). So with time the generic approach (OpenCL or like) will become better and better, and less and less people will develop for a target as the decreasing performance advantage won't justify the cost. This process will not necessarily be fast ;) and we're just starting.

Re:The first problem that comes to mind..

[MrHanky]

One reason why laptop sales passed desktop sales is of course that desktops last longer, due to their upgradeability.