AMD reverses GPGPU trend, announces OpenCL SDK for x86

http://arstechnica.com/hardware/news/2009/08/amd-announces-opencl-sdk-for-x86.ars

by habs • 17 years ago

38 27 17 years ago

jacquesm7• 17 years ago

Interesting development! One thing I don't get is if you are developing stuff for GPGPUs and you don't have one yourself that getting one is hardly a big hurdle.

The cheapest cards that will work are in the $100 range, hardly a major expense.

The GPGPU is probably one of the biggest developments in the last couple of years, it puts enormous power in the hands of individuals with a surprisingly small power bill and footprint.

~300W for a 480 core machine is not bad at all!

scott_s6• 17 years ago

Enormous, but extremely specialized power.

I'm not sure if most people understand the kinds of threads/cores that GPUs actually have, and with that, the kinds of computations they're actually good at. A GPU's threads are extremely simple execution pipelines - nothing like the cores of an Intel Quad Core chip. Groups of GPU threads actually execute together in lock-step, executing the same code (but with different parameters).

Such devices are extremely good at handling data parallelism - where the same computation is performed on a large chunk of data - seen in areas such as graphics and scientific computing. But you're probably not going to, say, speed up your webserver with a GPU. If you don't have a computation that is extremely data parallel - that is, capable of having thousands of execution contexts working on data at the same time - a GPU won't help.

jacquesm7• 17 years ago

The model is parallel SIMD, so in other words, multiple banks of cores, within each bank all the cores are doing the same thing at the same time.

A GPU won't help with our current programming model, maybe there is room for a new model then ?

That won't happen overnight, but one thing is for sure, if you want to get more performance than what your applications are giving you today then you'd better learn how to code for massively parallel systems.

apu2• 17 years ago

Things are changing extremely rapidly.

Researchers (especially in parallel computing) are already figuring out how to port all sorts of algorithms over to the GPU -- and not just scientific or graphics code -- we're talking general purpose algorithms like sorting, ranking, cryptography, networking, database operations, etc:

http://gpgpu.org/2009/04/13/efficient-acceleration-of-asymme...

http://gpgpu.org/2009/04/28/fast-and-scalable-list-ranking-o...

http://gpgpu.org/2008/12/11/wait-free-programming-for-genera...

http://gpgpu.org/2008/10/26/gnort-high-performance-network-i...

http://gpgpu.org/2008/05/25/a-fast-similarity-join-algorithm...

The biggest obstacle to preventing widespread adoption of GPGPU techniques today is that things are still in so much flux that mature, stable APIs have not yet emerged. There is fierce competition between Intel (Larrabee), Apple/AMD (Grand Central/OpenCL), and NVIDIA (CUDA) to get their respective APIs to be the dominant ones, and no one's yet come up with a mature wrapper API that can target any of them.

This is in large part because the hardware itself is still in flux, morphing away from the graphics-specific pipeline of 10 years ago and into a general purpose SIMD architecture. This has meant a change in the kinds of operations allowed on the GPU. For example, branches used to be a big no-no in graphics hardware: the performance hit caused by a branch was disastrous on a massively-multicore system. However, all hardware makers are now adding supporting for branches, because it's almost impossible to port a lot of CPU algorithms without them.

In any case, I'm confident that within a year or two, things will have settled down somewhat, at which point there's going to be a mad dash by developers to start using GPUs (probably systems- and library-level developers rather than application-programmers).

yhgtgygv• 17 years ago

It is a great boost to the adoption of openCL: The difference between;

Use this new technology and your app will be faster - but will only work if your customers have one of this range of graphics cards.

Your customers will get a huge speedup if they have a supported card, but it will still work if they don't.

It's like the software floating point emulators back in the 386 days

pmorici• 17 years ago

This looks to me like a publicity stunt since ATI's original GPGPU offering was a flop. Nvidia's OpenCL SDK actually works on their graphics cards though it is in limited beta last I checked.

jacquesm7• 17 years ago

yep. You can register here:

http://www.nvidia.com/object/cuda_opencl.html

I think that's just their way of making sure they don't lose track of where their possibly still very buggy software goes so that they can get the feedback and tell their users when it's time to upgrade.

The differences with CUDA are so small though that it is fine to develop for CUDA now and upgrade to OpenCL when they release it publicly.

lutorm2• 17 years ago

Not to mention that you can compile CUDA code in "emulation" mode for execution on the CPU, too. The utility is largely for debugging, because the CPU is darned slow executing it, so I'm not sure it has any use in production.

yan• 17 years ago

I guess I'm not understanding something. How are they reversing a trend?

Apple spent a lot of time and money developing the OpenCL standard and gaining industry support. OpenCL isn't strictly about GPGPU computing, it's about maximally utilizing available resources. AMD is adopting the standard, and they just implemented the CPU portion of it for now and went ahead to release it. There is no doubt in anyone's mind that they'll follow up with supporting GPU target. So if anything, they're embracing the trend, just trying to bring their tools to completion.

So yeah, the current SDK doesn't support GPU targets, but how is this in any way shape or form reversing the trend?

plesn• 17 years ago

Exactly, I would even argue that without OpenCL on CPU (which can serve e.g. as a fall-back when your GPU can't do it), OpenCL wouldn't make sense.

Keyframe• 17 years ago

Do not forget that intel released a C++ Larrabee Prototype Library for anyone wanting to experiment. Just sayin'...

dlevine• 17 years ago

I feel like CPUs and GPUS are converging anyways. They are both going multicore, and GPUs are becoming better suited to general-purpose processing. Sure GPUs have lots of simple dedicated cores, while CPUs have fewer more complex cores, but over time this will converge.

In the long run, you won't need dedicated logic for graphics processing, at least on the low-end. Processors will just dedicate a few cores to graphics processing.

If you doubt this, look at what people said a few years ago about graphics integrated into the chipset. Now you have respectable solutions like NVidia's 9400. Within a few years, I bet that some relatively high-end solutions will be integrated into the silicon, and the low-end processors will do everything on the CPU. Over the long-term (probably when we have 32-64 cores per CPU), the GPU will become irrelevant.

lutorm2• 17 years ago

I don't think they are converging at all. The fundamental difference is that GPUs are using the vast amount of silicon real estate that in a CPU is used for cache for computational units. That gives it much higher computational peak performance, but it also means that your memory is uncached, which will kill you in applications that do unstructured memory access.

I think of it as analogous to cars vs semitrucks. Trucks are efficient at hauling massive amounts of stuff to the same place, but not at transporting 100 commuters to their different workplaces. They are optimized for different problems and I don't think there's a better argument for saying that GPUS and CPUs will converge than to say that semitrucks and cars will converge.

scott_s6• 17 years ago

But GPUs do have an internal memory hierarchy; there is a local cache with much faster access times than global memory.

Personally, I agree with the parent. Aside from the obvious solution of integrating a GPU-like accelerator on the chip, the multicore trend in general purpose CPUs has more, simpler cores. I agree with your overall characterization of what CPUs are good at versus what GPUs are good at, but I still see some convergence.

zandorg• 17 years ago

Does this come with an emulator for Windows, so you can test it without a GPU?

AMD reverses GPGPU trend, announces OpenCL SDK for x86

Related Stories