An Open Source Compiler From CUDA To X86-Multicore

Gregory Diamos writes "An open source project, Ocelot, has recently released a just-in-time compiler for CUDA, allowing the same programs to be run on NVIDIA GPUs or x86 CPUs and providing an alternative to OpenCL. A description of the compiler was recently posted on the NVIDIA forums. The compiler works by translating GPU instructions to LLVM and then generating native code for any LLVM target. It has been validated against over 100 CUDA applications. All of the code is available under the New BSD license."

Comments

Alternative?

[Guspaz]

This isn't an alternative to CUDA; it lets CUDA code run on x86, but still doesn't do anything for AMD graphics cards. In other words, your choices as a developer are to use OpenCL and have your code run everywhere (AMD, nVidia, x86 slowly), or use CUDA and have your code run on nVidia or x86 slowly.

What possible reason could you have to want to be locked into one GPU vendor?

Re:Alternative?

[Anonymous Coward]

I think Cuda was first out there, later on OpenCL occurred. And i see it as bad thing really, since that binds you to using Nvidia card. I hope it wont become popular i dont want to stick to Nvidia.(ot, when AMD has Linux drivers open sourced)

Re:Alternative?

[Guspaz]

Progressively more and more.

Example: Go to "ati.com" and you get redirected to the regular amd.com front page. Go to desktop graphics products and you get a page titled "AMD Graphics for Desktop PCs" inviting you to shop for "AMD Desktop Graphics Cards".

The actual cards themselves have as product name "ATI Radeon", but describing an "ATI Radeon" as an "AMD graphics card" is accurate.

Wait wut?

[Icegryphon]

Why would you go from CUDA(Fast Floating-points) to x86(slower Floating-points)?
Is there support yet for double-precision floating points yet on Nvidia cards?
This makes as much sense as a Wookiee on the planet Endor.
Unless the Point is portability but, then why write it in Cuda to begin with?

Re:Wait wut?

[tepples]

Why would you go from CUDA(Fast Floating-points) to x86(slower Floating-points)?

For running legacy apps that were developed between the release of CUDA and the release of OpenCL. There aren't many, I'd guess.

Re:Wait wut?

[SpinyNorman]

I can think of a couple of reasons it may be useful on x86 :

- Better debugging tools
- Allows CUDA development without buying specialized hardware up-front (a lesson I've learnt - don't buy hardware until the software is ready)

It's also another option for multi-core programming. If the CUDA API is good, maybe it's an efficient way to develop certain types of parallel apps even if you never intend to use it on a GPU.

CUDA is only fast on some computers

[Anonymous Coward]

Why would you go from CUDA(Fast Floating-points) to x86(slower Floating-points)?

Because if you don't have the right hardware, CUDA isn't fast floats. It's a program that doesn't run at all.

OpenCL not a magic bullet

[smcdow]

A bit off topic, but since I'm seeing posts about OpenCL and portability...

OpenCL will indeed get you portability between processors, however OpenCL does not make any guarantees about how well that portable code will run. In the end, to get optimum performance you still have to code to the particular architecture on which that your code is going to run. For example, performance on Nvidia chips is extremely sensitive to memory access patterns. You could write OpenCL code that runs very well on Nvidia chips, but runs poorly on a different architecture.

Not saying that portability isn't a good thing, but a lot of people seem to be thinking that OpenCL will solve all your portability problems. It won't. It only will let code run on multiple architectures. You'll still have to more or less hand optimize to the architecture.