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

Re:The first problem that comes to mind..

[Rosco P. Coltrane]

I think only a small number of computer users upgrade components these days - gamers and power users. But the majority of people these days buy a beige box or a laptop and never ever open them. From a business point of view, combining the GPU and the CPU makes sense. Heck, nobody cried when separate math coprocessors disappeared.

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:AMD's next strike against intel

[myurr]

Except Larrabee failed because performance didn't live up to expectations and was a generation behind the best from AMD and nVidia. What this development from AMD allows is much more efficient interaction and sharing of data between a traditional CPU and an on-die GPU through updates to the memory architecture. These memory changes will also allow the parts to take advantage of the very fastest DDR3 memory that current CPUs struggle to fully utilise.

The two most obvious scenarios for this technology are for accelerating traditional problems that take advantage of the existing vector units (SSE, etc.) by utilising the integrated GPU to massively accelerate these programs, and in gaming rigs where there is a discrete GPU the new architecture allows the integrated GPU to share some of the workload. The example given, and one that is increasingly relevant as all games now have physics engines, is for the discrete GPU to concentrate on pushing pixels to the screen and the integrated GPU to be used to accelerate the physics engine.

Is it a game changer? Probably not in the first couple of generations, although it would be a very welcome boost to AMDs platform that could get them back in the game as the preferred CPU maker. But long term Intel will have to come up with an answer to this in some form as programmers get ever more adept at exploiting the GPU for general purpose computing, and changes like those AMD are incorporating into their designs make these techniques ever more powerful and relevant to wider ranges of problems. Adding more x86 cores won't necessarily be the answer.

Re:Long time coming

[TheRaven64]

It's not that difficult to write code that takes full advantage of modern hardware. The limitation is need. Every 18 months, we get a new generation of processors that can easily do everything that the previous generation could just about manage. Something like an IBM 1401 took a weekend to run all of the payroll calculations for a medium sized company in 1960, using heavily optimised FORTRAN (back when Fortran was written in all caps). Now, the same calculations written in interpreted VBA in a spreadsheet on a cheap laptop will run in under a second.

It would be naive to say that computers are fast enough - that's been said every year for the last 30 or so, and been wrong every time - but the number of problems for which efficient use of computational resources is no longer important grows constantly. Look at the number of applications written in languages like Python and Ruby and then run in primitive AST interpreters. A decent compiler could run them 10-100x faster, but there's no need because they're already running much faster than required. I work on compiler optimisations, and it's slightly disheartening when you realise that the difference that your latest improvements make is not a change from infeasible to feasible, it's a change from using 10% of the CPU to using 5%.

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.

Re:Long time coming

[TheRaven64]

Not really. Now the CPU spends 95% of its time waiting for data from the network or disk instead of 90%, but the CPU is rarely the bottleneck these days.

Around the time of the Pentium II, Intel did some simulations where they increased the (simulated) speed of the CPU running typical applications and measured performance. They found that, if the speed of other components didn't change, an infinitely fast CPU (i.e. all CPU operations took 0 simulation time) ran about twice as fast as the ones that they were shipping. It doesn't take much of an improvement in CPU speed before the CPU just isn't the bottleneck anymore, even in processor intensive tasks. RAM and disk bandwidth and latency quickly take over. This was one of the problems Apple had with the PowerPC G4 - the RAM wasn't fast enough to supply it with data as fast as it could process it, so it rarely came close to its theoretical maximum speed.

Will it run Linux?

[vigour]

Will it run Linux?

I'm not being facetious, I got stung by the lack of support by Nvidia for their Optimus graphics cards on my ASUS U30JC.

Thankfully Martin Juhl has been working on a solution using VirtualGL, which gives us the use of our Nvidia cards under linux

Re:Will it run Linux?

[fuzzyfuzzyfungus]

I would(given ATI's historically somewhat weak driver team) be wholly unsurprised to see some rather messy teething pains; but(given AMD's historical friendliness, and the long-term trajectory of this plan), I suspect that it will actually be a boon to Linux and similar.

The long term plan, it appears, would be to integrate the GPU sufficiently tightly with the CPU that it becomes, in effect, an instruction-set extension specialized for certain tasks, like SSE on steroids. If they reach that point, you'll basically have a CPU where running OpenGL "in software" is the same as running it "in hardware" on the embedded graphics board, because the embedded graphics board is simply the hardware implementation of some of the available CPU instructions, along with a few displayport interfaces and some monitor-management housekeeping.

I'd be unsurprised, as with Optimus, to see some laptops released with an embedded/discrete GPU combination that is fucked in one way or another under anything that isn't the latest Windows, possibly making the discrete invisible, possibly forcing you to run the discrete all the time, or some other dysfunctional situation; but I'd tend to be optimistic about the long term: GPU driver support has always been a sore spot. Compiler support for CPU instructions, on the other hand, has generally been pretty good.

Re:Long time coming

[pandrijeczko]

I think what is going to be really interesting is to see what this does to PC gaming from the perspective of non-Windows operating systems.

APUs are clearly a step forward in the direction of putting powerful graphics processing on portable devices, an area where Microsoft and Windows has very little marketshare at the moment.

Therefore, this surely must bring DirectX's domination in the PC gaming market into question - will this therefore result in more commercial games being developed around OpenGL, thus making cross-platform games much easier to develop?