An Open Source Compiler From CUDA To X86-Multicore 71
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."
Alternative? (Score:5, Insightful)
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: (Score:2, Insightful)
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: (Score:2, Informative)
Pardon? OpenCL does not in any way bind you to an nVidia card, it was a standard created by Apple (not nVidia) and pushed to Khronos to manage as an open standard (also not nVidia). ATI have just announced drivers for their cards for OpenCL.
Re:Alternative? (Score:4, Informative)
He means CUDA was here first, and it does(did) lock you into Nvidia. So if you jumped on the bandwagon early, your code is Nvidia only. If you waited for a standard (opencl) (or ported your app) then you're cross-platform.
Re: (Score:3, Informative)
On top of that, the CUDA tools are still much better than OpenCL. OpenCL is basically equivalent to CUDA's low-level "driver" interface, but it has no equivalent to the high-level interface that lets you combine host/device code in a single source, etc. CUDA also supports a subset of C++ for device code (e.g. templates), which I don't believe is the case for OpenCL. CUDA also has a debugger (of sorts), profiler, and in version 3 apparently a memory checker. But I haven't been following OpenCL that closely l
Re: (Score:3, Informative)
I think Cuda was first out there, later on OpenCL occurred.
Yes and no. CUDA and CTM/Brook+/FireStream came to live more or less at the same time when NVIDIA and ATI realized that GPGPU (General Purpose computing on the GPU) was getting traction in the scientific computing world (originally implemented using OpenGL and shaders).
OpenCL was essentially an effort (by Apple first and foremost, although obviously with cooperation from both NVIDIA and ATI) to get a standardized interface to SIMD multicore programming. It's actually quite close to low-level CUDA programm
Re: (Score:2)
As far as I can tell, OpenCL is pretty much based on CUDA, not on an attempt to unify CUDA and CTM/Brook+/FireStream. That's partly because ATI's solutions never really caught on, and have been sorta ignored.
Re: (Score:2, Informative)
OpenCL isn't ALL that close either to CUDA or anything from AMD (CAL, Brook+). The status quo with AMD is that the OpenCL implementation they have is very immature e.g. doesn't support a lot of fairly basic and highly desirable OpenCL "extensions" (actually it didn't support ANY until about 2 days ago, and now they're just beta testing a few of the most rudimentary ones). Additionally there are still lots of issues with missing / unclear documentation, missing features, bugs, development / runtime platfor
Re: (Score:2)
OpenCL isn't ALL that close either to CUDA or anything from AMD (CAL, Brook+). The status quo with AMD is that the OpenCL implementation they have is very immature e.g. doesn't support a lot of fairly basic and highly desirable OpenCL "extensions" (actually it didn't support ANY until about 2 days ago, and now they're just beta testing a few of the most rudimentary ones). Additionally there are still lots of issues with missing / unclear documentation, missing features, bugs, development / runtime platform portability issues, et. al. Most significantly, the openCL performance is still a fraction of the performance commonly achievable with Brook+ or CAL in many common scenarios on the AMD platform. This is sometimes / often true for their 58xx series boards, and pervasively so for their older 4xxx series cards (which by architectural limitations as well as by lack of planned OpenCl development toolchain support / optimization will never really perform well with OpenCL).
On the NVIDIA side, CUDA performance and usage flexibility is still typically and substantially higher than is achievable via OpenCL, since obviously CUDA exists to fairly optimally exploit their GPU architectural capabilities whereas OpenCL is a generic GPU-vendor / architecture "neutral" platform that doesn't give as much card specific control as CUDA (or CAL in AMD's case).
I do wonder how much this is because of OpenCL being vendor-neutral and thus 'far' from the underlying architecture, and how much it depends on the quality of the compilers. I suspect that NVIDIA does not have much of an interest in optimizing their OpenCL compiler as much as they do with their CUDA compiler, for the obvious reason that with CUDA they have vendor lock-in and can sell more hardware, whereas with OpenCL there is the (remote) possibility that a better compiler from ATI might lead people to loo
Re: (Score:1)
That's not true. I've run many equivalent CUDA and OpenCL kernels on NVIDIA cards, and they perform both the same. Pretty much in ac
Re: (Score:3, Funny)
Hard to say, but it must be easy since there are lots of mods that are, at the very least, a bit challenged. If you know what I mean.
Re: (Score:1, Offtopic)
<The Tick>
Nope.
</The Tick>
Ok, that one was strictly for the two other people who would get a Warburton/Tick reference. But the three of us laughed our asses off..... "Yes, it is I, Bat-Manuel! I saved them three times later that night, if you know what I mean." Heh, funny..
Re: (Score:3, Interesting)
When did AMD drop the ATI brand?
Re: (Score:3, Funny)
Wednesday December 23, @02:11PM
Re:Alternative? (Score:4, Insightful)
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.
Re: (Score:2)
I'm not sure it would be wise for AMD to drop a known brand name like ATI.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Does it run as a last accessed, last executed, last used, last in, last out queue?
Re: (Score:1)
Re: (Score:3, Informative)
The reason is that today CUDA has a headstart and is more mature. Eventually things will probably shift to OpenCL but that takes time and people don't want to sacrifice features today.
Re: (Score:3, Informative)
I've seen feature requests suggesting they are considering it, but at the moment too much information is lost in the PTX->LLVM step to be able to generate CAL or OpenCL.
Re: (Score:3, Informative)
Here it is :
http://code.google.com/p/gpuocelot/issues/detail?id=30 [google.com]
Re:Alternative? (Score:4, Informative)
The greatest challenges lie in accommodating arbitrary control flow among threads within a cooperative thread array. NVIDIA GPUs are SIMD multiprocessors, but they include a thread activity stack that enables serialization of threads when they reach diverging branches. Without hardware support, this kind of thing becomes difficult on SIMD processors which is why Ocelot doesn't include support for SSE yet. It is also one of the obstacles for supporting AMD/ATI IL at the moment, though solutions are in order.
Translation from PTX to LLVM to multicore x86 does not necessarily throw away information concerning the PTX thread hierarchy initially. The first step is to express a PTX kernel using LLVM instructions and intrinsic function calls. This phase is [theoretically] invertible and no information concerning correctness or parallelism is lost.
To get to multicore from here, a second phase of transformations insert loops around blocks of code within the kernel to implement fine-grain multithreading. This is the part that isn't necessarily invertible or easy to translate back to GPU architectures and is what is referenced in the note you are citing.
Disclosure: I'm one of the core contributors to the Ocelot project.
Re: (Score:2)
What possible reason could you have to want to be locked into one GPU vendor?
Hardware, libraries, and Toolkit.
Cuda was useable way before anything else
At the Time Cuda came out AMD was using CTM [wikipedia.org].
Which is absolutely Painful to use.
Re:Alternative? (Score:5, Informative)
it lets CUDA code run on x86, but still doesn't do anything for AMD graphics cards
Actually, it does. It lets CUDA code run on any processor that has an LLVM back end. The open source Radeon drivers have an experimental LLVM back end and use LLVM for optimising shader code.
Re: (Score:2)
Because the hardware doesn't suck?
We'll see about that in 2Q10, the earliest that Fermi could be released. This assumes nVidia avoids bankruptcy and can get the steaming pile poo known as Fermi to actually work acceptably and reliably enough for general release to "consumers".
Because (Score:2)
"What possible reason could you have to want to be locked into one GPU vendor?"
Perhaps because you are sick and tired of GPUs that don't die an early death, and love sitting on the phone and being told that it isn't covered by warranty by HP, Dell, Apple, Sony, and the rest.
-Charlie
Re: (Score:1)
What possible reason could you have to want to be locked into one GPU vendor?
Only that the other GPU Vendor, AMD/ATI, doesn't have a working Linux driver for 3-d, proprietary or open. In addition there isn't much support for their older cards,
Re: (Score:1)
Performance? (Score:2)
I wonder how the performance of the open source solution is compared to the proprietary compiler by NVidia. If it's good enough, they might be scared.
Re: (Score:2)
scared ? they should be happy.
Re: (Score:1)
Wait wut? (Score:4, Insightful)
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? (Score:4, Insightful)
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: (Score:2)
This assumes that your GPU can perform (or that you can deal without) double precision operations, can carrying out renormalization, offer rounding as well as chopping, and properly handle "Not a Number" or Infinity values by following the IEEE754 standards.
Re: (Score:3, Interesting)
For running legacy apps that were developed between the release of CUDA and the release of OpenCL. There aren't many, I'd guess.
Sounds like there is great potential for a tool that will convert CUDA to OpenCL.
Re: (Score:1)
Re: (Score:2)
Re: (Score:1, Interesting)
Suppose you have working CUDA code but your dataset is relatively small, say a block of 1000 floating point numbers. Then the overhead of delegating the work to the GPU isn't necessarily worth the trouble.
Re: (Score:3, Informative)
Which is exactly why you should be using OpenCL, not CUDA – because it lets the OpenCL driver decide whether to run it on the CPU or the GPU.
Re: (Score:2)
It doesn't really, though. OpenCL "decides" based on some very high-level, high-granularity features of devices it can enumerate. In practice, if you want your code to run reasonably well, you know which parts are going to run on the GPU and which on the CPU. OpenCL isn't an auto-parallelization solution, just a set of primitives for parallel programming--- more like an MPI or OpenMP that also supports GPGPU than the old 70s holy grain of auto-parallelizing where the compiler or runtime magically figures ou
Re: (Score:2)
Very true, to get that, you need to combine OpenCL with Grand Central Dispatch.
Re: (Score:3, Insightful)
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 (Score:1, Insightful)
Because if you don't have the right hardware, CUDA isn't fast floats. It's a program that doesn't run at all.
Doesn't sound like a compiler (Score:4, Interesting)
Recompiler to what back-end? (Score:2)
And if it is just a front-end for LLVM, then why doesn't it support ATI graphics cards?
That depends on whether LLVM has a back-end for ATI graphics cards. Is the Stream Computing SDK based on LLVM or something else?
Re: (Score:2)
Seems to be just a front-end for LLVM. And if it is just a front-end for LLVM, then why doesn't it support ATI graphics cards?
Because OpenCL already does that job just fine. The only possible use for this is to have legacy CUDA apps actually run while people port them to use OpenCL instead.
Re:Doesn't sound like a compiler (Score:4, Informative)
There is no LLVM backend for AMD/ATI cards. Of the few of us that actually understand ATI hardware, most of us are working on other things besides GPGPU. Sorry.
Re: (Score:2)
I'm betting.. (Score:3, Funny)
just-in-time compiler? (Score:1, Troll)
Doesn't that mean "not compiled at all"
Re: (Score:2)
No, it means compiled just in time. Shocking, I know.
OpenCL not a magic bullet (Score:4, Insightful)
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.
Re: (Score:3, Informative)
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.
Like the argument of assembler vs C, I think as time goes on we will find ourselves with code that can do a better job of optimising the code for a specific processing core, given a block of OpenCL code than the programmer. Sure there will
Re: (Score:1)
Re: (Score:2)
In general, high-level languages have more potential for optimization than low-level ones. In contrast, low-level languages make it easier for the program
Re: (Score:2)
Why? (Score:3, Informative)
So there seem to be several questions as to why people would want to use CUDA when an open standard exists for the same thing (OpenCL).
Well, honestly, the reason why I wrote this was because when I started, OpenCL did not exist.
I have heard the following reasons why some people prefer CUDA over OpenCL:
Additionally I would like to see a programming model like CUDA or OpenCL replace the most widespread models in industry (threads, openmp, mpi, etc...). CUDA and OpenCL are each examples of Bulk Synchronous Parallel [wikipedia.org] models, which explicitly are designed with the idea that communication latency and core count will increase over time. Although I think that it is a long shot, I would like to see more applications written in these languages so there is a migration path for developers who do not want to write specialized applications for GPUs, but can instead write an application for a CPU that can take advantage of future CPUs with multiple cores, or GPUs with a large degree of fine-grained parallelism.
Most of the codebase for Ocelot could be re-used for OpenCL. The intermediate representation for each language is very similar, with the main differences being in the runtime.
Please try to tear down these arguments, it really does help.
The worlds only Ocelot joke (Score:1)
Q: How do you titilate an ocelot?
A: Oscillate it's tits a lot.
I thank you.