Slashdot Mirror
AMD's Fusion Processor Combines CPU and GPU
ElectricSteve writes "At Computex 2010 AMD gave the first public demonstration of its Fusion processor, which combines the Central Processing Unit (CPU) and Graphics Processing Unit (GPU) on a single chip. The AMD Fusion family of Accelerated Processing Units not only adds another acronym to the computer lexicon, but ushers is what AMD says is a significant shift in processor architecture and capabilities. Many of the improvements stem from eliminating the chip-to-chip linkage that adds latency to memory operations and consumes power — moving electrons across a chip takes less energy than moving these same electrons between two chips. The co-location of all key elements on one chip also allows a holistic approach to power management of the APU. Various parts of the chip can be powered up or down depending on workloads."
Heh. They should use Apu from the Simpsons in their advertising...
This could be interesting. Intel might have to change plans for Larrabee again.
“Hundreds of millions of us now create, interact with, and share intensely visual digital content,” said Rick Bergman, senior vice president and general manager, AMD Product Group. “This explosion in multimedia requires new applications and new ways to manage and manipulate data."
So people watch video and play video games, and it's still kinda pokey at times. We're way past diminishing marginal returns on improving graphical interfaces.
I bring it up, because if you're trying to promote a technology that actually uses a computer to compute, you know, work with actual data, you are perpetually sidetracked by trying to make it look pretty to get any attention.
Case in point: working on a project to track trends over financial data, there were several contractors competing. One had this software that tried to glom everything into a node and vector graph, which looked really pretty, but didn't actually do anything to analyze the data.
But to managers, all they see is that those guys have pretty graphs in their demos and all we had was our research into the actual data... all those boring details.
I wonder how well it would work in a virtualization environment such as VMware, Xen, KVM, etc. I could really see a point to a server that could easily off-load GPU work from thinclients that are running virtual desktops without needing to manage a huge box full of GPU cards.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
That's hot! Now I'll need only one big cooler instead of many small ones. Is it possible to use these GPUs easily in my own apps? What kinds of compilers we have for these? Will this start an era of functional programming?
"Moving electrons between two chips" isn't entirely accurate. What moves is a wave of electric potential; the electrons themselves don't actually move very far.
I'm hoping moving things into the CPU will make it easier to take advantage of the huge parallel architecture of modern GPUs.
For what, you ask?
I'm personally interested in sound synthesis. I play the piano, and while you can get huge sample libraries (> 10 GB), they're not realistic enough when it comes to the dynamics.
Instead people have been researching physical models of the piano. So you simulate a piano in software, or the main components of it, and extract the sound from that. Nowadays there are even commercial offerings, like Pianoteq (www.pianoteq.com) and Roland's V-Piano. Problem is that while this improves dynamics dramatically, they're not accurate enough yet to produce a fully convincing tone.
I think that's partly because nobody understands how to model the piano fully yet, at least judging from the research literature I've read, but also very much because even a modern CPU simply can't deliver enough FLOPS.
Perhaps you should email your insights the CEO of AMD. I'm sure he'll be grateful for the heads up from some retarded cunt on slashdot that his huge array of engineers and scientists have being building a chip that doesn't work for the past 5 years.
Just like my Core i3 sitting about 20 inches to the left, then. Yes, I know they're incorporating a better GPU, but they're touting too much as new.
Let's party like it's 1995! Again!
Slightly less cynically, isn't this (in like-for-like terms) trading a general purpose CPU core for a specialised GPU one? It's not like we'll get more bang for our buck, we'll just get more floating point bangs, and fewer integer ones.
If you were blocking sigs, you wouldn't have to read this.
This is not going to make "faster gaming systems". It's just another, cheaper and lower power form of onboard graphics. Gamers are definitely still going to be using discrete graphics for now.
which is totally what she said
No, YOu cannot offload CPU work to GPU work with a virtualisation solution. Even if it was possible the network bottleneck would be far larger than most advantages gained.
And second, the GPU that is integrated has the same kind of processing power as current integrated (on the motherboard) solution. You can offload a little bit, but since there are power limits you do can expect very high gains. THe gains that exist will be used for power efficient laptops/notebooks or cheap desktops.
If you really have large amounts processing work to do that fits a GPU well, you can invest in a GPU card better that has a high power envelope. There are not many applications for this (relative to number of PC boxes), this will be a niche market (but even a small % of all pc sales is a big market...)
That all said, distributed project file like Boinc will only benefit from more opengl capacle GPUs in the field.
The new paradigm. Snort...
Heat will only be a problem if they aim to replace the video cards from (hardcore) gaming system...
Problably not.
I guess they are aiming for the largest market:
cheap, but "good enough" graphics for the lowest possible price point.
Maybe it will be also be used for physics acceleration and similar high-computing tasks but only time will tell.
Will the drivers for the graphics be open source or will we be crawling out of this proprietary driver hole we have been trying to climb out of for over a decade?
Indeed.
This GPU-on-the-CPU is targeting the mobile/lightweight market.
Think about how the other solutions work. That GPU chip sits next to the CPU chip and they both must be connected to the system bus in order to access ram. With AMD's solution here, you remove that GPU chip and therefor also remove the external BUS connection that it required. This is a very big win for manufacturers, who would even pay a premium for the chip because of the lower production costs. But knowing AMD, they wont be charging a premium for it. Instead they will try to push Atom's out of the market.
"His name was James Damore."
AMD chipsets with integrated GFX were quite good at power consumption already; using a dozen or so watts. Considering AMD puts out quadcores with sub 100W TDP, Fusion shouldn't be that big a problem.
One that hath name thou can not otter
jesus why is _this_ guy who is right on the money marked -1: troll? the troll is the guy he is responding to :\
Yes, heat is going to destroy this thing if they want to make it a Fermi plus an overclocked Extreme Edition processor.
However, if the graphic performance is limited based on available (main) memory bandwidth (from which the main processor also takes a chunk), they don't need more than a quarter of a 5850, and starting with a 65W TDP processor, they're in the 125W TDP (where they released plenty of processors).
If they drop graphic performance even further, they could get a desktop processor and a normal desktop graphic card under 95W TDP (and even mATX boards support/supported 95W AMD processors).
Looks like the Quickie Mart has a lawsuit on their hands.
There are no loopholes. It's either legal or it's not.
AMD designed/implemented the 64bit instruction that will be running our desktop PCs for decades to come.
Intel was the one scrambling to catch up on that.
No sig today...
This demo was of Ontario - AMD's low power solution for netbooks and low-end notebooks. This will be using the low power Bobcat cores and probably something similar to an HD5450 graphics-wise.
I seriously doubt heat is going to be an issue.
Because I said some swear words. I tried to resist, but it's just too satisfying.
Very few people need more than a dual-core - the cores just sit their twiddling their bits. Sacrifice a core or two for a good GPU, and you have massively simplified the design of the system, saved power and saved space.
Sure, it's not a new idea - in IT we seem to progress in spirals. It's time this idea came around again...
Enjoy life! This is not a dress rehearsal.
Sounds like a non-advancement to me.
"Look, we can build a VCR *into* the TV, so they're in one unit!"
Yeah, so when either breaks, neither is usable.
Putting more points of failure into a device just doesn't sound like a great idea.
In the last 4 computers I've built/had, they've gone through at least 6-7 graphics cards and 5 processors. I can't remember a single one where they both failed simultaneously.
Now, if this tech will reduce the likelihood of CPU/GPU failures (which, IMO, are generally due to heat or less frequently power issues) somehow, then great. But I have a gut reaction against taking two really hot, power-intensive components and jamming them into even closer proximity.
Finally, I'm probably in the minority, but I prefer being able to take my components ala carte. There were many times in the past 25 years that I couldn't afford the best of all components TODAY, so I built a system with a very high-end mobo and CPU, but using my old soundboard, RAM, etc until I could afford individually to replace those components with peer-quality stuff.
-Styopa
This thing is going to smoke current CPUs in things like physic operations without the need of anything like CUDA and without the performance limit of the PCIe bus.
Ummm, but videocard has its own super-fast memory (and a lot of it), and it uses direct access to system RAM, while this little thing will have to share the memory access and caches with CPU.
without the need of anything like CUDA
I dare to say, that this is totally false.
I thought that they learned it is more efficient to have a seperate CPU and GPU.
Packing the GPU into the CPU makes a lot of sense but also raises some questions.
Does this mean that in the future we can have chips that contain not only a multi-core CPU but also a multi-core GPU? For example could AMD pump out a frag-tastic 6 CPU + 4 GPU chip for hardcore gamers and scientists?
How is this going to effect the cooling for the chip? If I fire up Crisis will my computer melt? (Assuming a GPU is packed in with enough power to play crisis.)
Also how is this going to effect memory bandwidth? Most graphics cards come with some pretty high throughput memory to make everything work. Once everyone is on 64bit having the extra RAM for the GPU is not a problem, but what about the bandwidth?
With all of this multicore processor stuff, I get the feeling that we are going to hit upon another memory bandwidth limit very soon.
I must admit, I was disappointed that you didn't go for the more gerund-y "cunting retard".
Back in the days of Athlon64 vs Pentium 4 and Itanium AMD were ahead. Still since Core2 I'd say Intel are doing better. That being said Larrabee seems to be dead and I still think the idea has legs. Hopefully AMD will be to Larrabee what AMD64 was to IA64 - i.e. a more pragmatic version of the idea that ends up working better.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Unless I'm totally missing something, there's no question as to electron mobility.
Can you provide any links?
"retarded cunt" is completely offensive and a terrible distraction which hinders your message.
In the interest of sensitivity, please use the term to "mentally challenged cunt" in future.
Thank you.
"This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
Many of the improvements stem from eliminating the chip-to-chip linkage that adds latency to memory operations and consumes power - moving electrons across a chip takes less energy than moving these same electrons between two chips. The co-location of all key elements on one chip also allows a holistic approach to power management of the APU.
Dual-core shared-cache architectures wreaked havoc on kernel security when they were first introduced - and we still aren't entirely certain that our operating systems are fully secure against shared-cache exploits - we seem to get about a new one about every six to twelve months.
So are the kernel [& micro-kernel] and driver guys fairly confident that we won't be getting incestuous security problems when kernels and drivers start sharing the same silicon?
I predict an initial round of exploits as the kernel guys have to re-learn their approaches to hardening their operating systems against the graphics drivers.
In the discrete GPU system as we have it, data gets pulled from memory to the CPU for processing/caching and the result is sent through a bus to the GPU for rendering. Maybe this whole thing took so long because AMD was working out a way to just read that data once, process it in the CPU, and leave it in the L1 cache for the GPU. If this is how it turns out, it really will make things much faster, because no discrete GPU has ever had access to data that's as quickly readable as the L1 cache. Now, maybe it will turn out that you just can't store enough data in L1 to make all the framebuffers and other graphics stuff work. (But maybe you can; since this thing does all the data processing "in one house", you can work through it chunk by L1-cache-sized chunk, and as soon as that stuff is processed and rendered by the Fusion unit, it is sent down the DVI cable and can be forgotten. Rinse and repeat, and you might have a formula for rendering scenes which actually moves very little data over the memory bus.)
Also remember that AMD owns the patents for ZRam. They could realistically make a very large and fast on-die caches with ZRam, and Intel couldn't respond because they don't own the rights and don't use a SOI process like AMD, which is required for ZRam.
On a hex core or greater chip, having one of the cores do something more usefully than one of the other mostly unused cores is a good idea. There are very, very few applications where the average end user isn't getting enough integer performance, and yet almost no gamer I know is completely satisfied with their FPS in a dozen or more games.
Then extrapolate down the road to when we have 12 core machines, and 8 are CPU and 4 or GPU..... This is going to help a lot in the graphics department, and at lower cost/heat/watts than the current market.
This is an obvious and good move by AMD. We are witnessing the beginning of the future.
I hold very few opinions. I hold information based on observation and fact. If you wish to disagree, please use facts.
The CEO and officers of AMD are too busy counting the boatloads of cash they were paid while the price of AMD stock tanked to be bothered with mundane things like designing or building anything. A while back, these guys actually got paid bonuses for driving AMD stock into the ground. I don't think they care much one way or another.
Wow, you mean AMD invented a way to go from 32->64 bits? Like Intel did from 8->16 and 16->32 bits? I don't know why people think AMD was so revolutionary for doing this, it's been done before.
In the old days, there was a physical chipset which sat between the GPU and the CPU.
But in this architecture, there is no physical barrier - they're on the same silicon.
Look for the bad guys to try to force the graphics drivers to sneak over and sniff the memory of the CPUs - I can imagine how they might be able to load some code in a pr0n movie that could tell some pointer in a GPU driver to point to addresses of cache which [at least ostensibly] belong to a CPU, at which point they should be able to read the cache.
And if they're lucky, their specially-crafte pr0n-videos might even be able to WRITE to the CPU cache, at which point they can probably pwn the entire operating system.
Hopefully AMD has put some thought into their implementation, and has some sort of hardware safeguards that force the GPU to always act as the "slave" of its masters [the CPUs], but, if not, then all Hades could break loose.
[And Intel probably won't put nearly as much thought into their implementation as AMD did with theirs.]
Uhm, maybe because no one else wanted to figure out the 32->64 bit scenario? Intel would rather shove a new micro-architecture down your throat and no one else could compete. Lucky for AMD, the whole NetBurst fiasco was blowing up in Intel's face at the time, or they never would have gotten anywhere. I don't think Fusion will be enough to trump Intel with Intel having another screwup like NetBurst, which doesn't seem to be happening, as since Core 2, Intel's designs have been top notch, albeit expensive. The only real thing AMD has going for it is that Intel doesn't really have anything primed as Larrabee seems to be dead in the water. Of course, Intel augmented AMD's 64-bit instruction set onto their CPUs and drowned their engineers with money to produce far more potent chips than AMD before, I can't imagine they wouldn't be able to do it again.
Anybody else remember when there were rumors in the air that IBM would scoop up AMD? That would have been a fun scenario.
"Now I am become Death, the destroyer of worlds"
AMD does not own the patents for ZRAM, it only licenses them like hynix. Innovative Silicon the holder of patents has announced that they will develop a non-SOI version of ZRAM. http://en.wikipedia.org/wiki/ZRAM
If you look at what we currently know about AMD's upcoming Bulldozer chip, which is designed for the server and high-end desktop markets, we see a chip with excellent performance in certain tasks (integer) but weak performance in others (floating point). This could be offset by the addition of Fusion-based technologies, especially because the Bulldozer's unit sharing strategy is similar to Fusion's, but their intended tasks are different. How this would find its way on a high-end desktop is beyond me, but it is something worth contemplating. It seems Intel may have been considering a similar approach in the recent past, but their dogged faith in the CPU has led them down a path focusing on brute force over experimental sophistication.
It's probably more likely that kernel developers will just need to adjust defense mechanisms to account for a new set of attack vectors.
Right - that was my original point, up at something like the GGP or GGGP level of this thread.
The kernel guys [and/or the Intel guys] were really sloppy when Intel first introduced dual-cores with shared-cache - we had all sorts of exploits where one core could sniff from a cache which [ostensibly] was supposed to have been the under the purview of another core.
And I'm saying that the kernel/microkernel guys - in conjunction with the hardware guys writing the drivers [ATi and the various "free"-lancers], and even the "application" guys, like the DirectX team at Microsoft, and the OpenGL crew - will all need to buckle down and put on their thinking caps and ask themselves: How are we going to harden the kernel [microkernel] against any incestous attack vectors coming from a GPU core which lives on the same silicon as the CPU cores? [And then they need to burn a little midnight oil to produce a stable implementation of their plans.]
Eventually they will get it right [and hopefully AMD has put a fair amount of thought into this already], but if anyone gets sloppy [from the AMD CPU team to the kernel/microkernel teams to the ATi driver team to the "applications" guys at DirectX and OpenGL], then we could be looking at some great big gaping holes in the security model.
Decades ago Intel changed from the separate integer and floating point processors (8086 and 8087, etc) to an integrated unit, because it was cheaper, faster, and more reliable. And because everyone wanted floating point, so there was no reason to separate them, and because Moore's Law said they could.
Now the GPU is being integrated, at least in the desktop chips. It's not so clear that everyone wants the fancy effects, 3D rendering, wobbly windows, and all the rest of the things vendors tout which are mostly aimed at game players. I think the percentage of users who need, want, or even tolerate those effects is smaller than the percentage who wanted floating point, but if it reduces the size, power, and cost of a computer with video, the average user will be happy, even if the bulk of the features are unused.
Note that Intel has added graphics in their i5-661 (and other) chips, although they seem to be more targeted to users who use only light duty graphics, and don't benefit from vast rendering capability. The market will decide the value of these changes, and the price will fall in line.
Sadly Itanium would have been better than x86-64. It's a shame it never did take over.
Ogre Wedding Planners llc.
And it would have never caught on anyways. With or without x86-64. Why? Same reason there are enterprises running out of date IBM computers and won't move up: Compatibility. I consider x86-64 a good thing because it gave us compatibility and still moved the game forward. And any forward momentum that allows us to keep going without having to reinvent every part of the wheel is good.
"Now I am become Death, the destroyer of worlds"