5 ms·

This is very cool. I really hope that GPU programming becomes increasingly tightly integrated into more languages over time. If we could reach a point where ev

This is very cool. I really hope that GPU programming becomes increasingly tightly integrated into more languages over time. If we could reach a point where every major compiler has GPU support built into the language itself, it would be so much easier for a thriving ecosystem of libraries and other supporting software to emerge (not that this doesn't exist already, but right now it's mostly divided into different groups for each GPU vendor, sadly). Unfortunately the GPU vendor divide still exists (mainly CUDA for NVIDIA, and OpenCL for AMD/Intel) with no immediately obvious solution. For example even the Rust-to-PTX compiler from this article will fail if you try to run it on AMD, or Intel, or anything but NVIDIA because PTX is an NVIDIA-only pseudo-assembly intermediate format. Projects like "gpuocelot" promise to translate PTX to run on other GPUs, but until such translation layers reach maturity (and don't sacrifice any performance in the process of translation), OpenCL will remain the only viable "intermediate" format that is truly GPU-agnostic. Which is really a shame, because quite frankly OpenCL is horrible to develop for multiple GPUs, because each GPU vendor has their own OpenCL compiler with a slightly different interpretation of the spec (not to mention severe performance differences between OpenCL and CUDA for NVIDIA GPUs), plus their own proprietary extensions. It's like writing C code that has to run on N different, immature, and mostly quirky compilers all with their own different subset of features, where N is completely unknown to you -- in fact N will grow over time after you release your application.

pjmlp 13y ago
You forgot Renderscript for Android. Google doesn't seem very keen in supporting OpenCL.
foxhill 13y ago
i don't understand what's horrible about OpenCL for all the vendors? aside from beta platforms, i've had all my codes work across platforms that claim to support the full profile. also, gpuocelot is a terrible idea. it's a reimplementation of a closed standard, entirely controlled by nvidia. it will always be catching up to CUDA. the thing is, we already have a portable binary solution in OpenCL, SPIR. it's just a dialect of llvm-ir, in fact. projects like this (that use CUDA/closed standards) are just deepening the divide between the GPU vendors, and moves us away from a single open standard.
- goldenkey 13y ago
  CUDA doesn't break any divide. It's not a closed standard at all. It's a platform specific standard. Nvidia has OpenCL support on their cards too, and its within 10% of the performance of CUDA. CUDA is just very optimized for the architecture, is all.
  - foxhill 13y ago
    so how does one go about proposing additions or changes to CUDA? ironically, i've been able to get more performance from OpenCL than CUDA (mostly due in part to OpenCL's dual-source model, it allows me to compile runtime constants into kernels). CUDA is no more "optimised" than OpenCL. it's the same compiler that generates kernels. enqueueRead/Write calls end up being cudaMemcpy, etc.
    - goldenkey 13y ago
      You can compile runtime constants into CUDA too. CUDA has both a driver api AND the standard C toolkit. CUDA is a lot more optimized than OpenCL when you use it right. Many of the library functions perform better than there OpenCL equivalents or take different types. Having used both, I've got to say that OpenCL is craptastic compared to CUDA. One big example is the fact that you can't set a kernel-wide global in OpenCL, you have to pass it to the kernel every time as a buffer. In CUDA you can lookup the global by symbol, and set it, and it remains persistent. That means the CUDA kernel func will have a slightly smaller stack size from not having all these craptastic persistent args passed to the kernel every time. Also, instead of dereferencing a pointer that is passed as a kernel arg, you are directly using the global, again, code optimized. You haven't used CUDA enough probably. I understand how on the surface they appear similar. But wholly, CUDA is better thought out.
      - foxhill 13y ago
        it's not the standard programming model in CUDA. the library functions compile down to the same PTX, it's the exactly the same toolchain wether you use nvcc or clBuildProgram - if you could provide an example indicating otherwise, i'd very much like to see it. you most certainly can set a kernel-wide global in OpenCL, and it does not need to be a buffer object. and you don't need to re-set it between kernel invocations (this would be true even if it were a buffer object). OpenCL is certainly verbose, but honestly, given that you may have multiple implementations of it on the same machine, i don't really see how it could be done any simpler (at least from the C API perspective). i use CUDA and OpenCL every working day. it is literally what i am employed to do.
jevinskie 13y ago
The great thing about LLVM is its multitude of backends. I bet this Rust-to-PTX compiler would require just a bit of work to run using the R600 LLVM backend that targets AMD GPUs.
fdej 13y ago
> It's like writing C code that has to run on N different, immature, and mostly quirky compilers all with their own different subset of features, where N is completely unknown to you -- in fact N will grow over time after you release your application. In other words, it's like writing C code :-) (At least, if you require fancy features such as inline assembly, threads, string literals longer than 509 characters, 64-bit integers, ...)

pjmlp 13y ago

You forgot Renderscript for Android. Google doesn't seem very keen in supporting OpenCL.

foxhill 13y ago

i don't understand what's horrible about OpenCL for all the vendors? aside from beta platforms, i've had all my codes work across platforms that claim to support the full profile. also, gpuocelot is a terrible idea. it's a reimplementation of a closed standard, entirely controlled by nvidia. it will always be catching up to CUDA. the thing is, we already have a portable binary solution in OpenCL, SPIR. it's just a dialect of llvm-ir, in fact. projects like this (that use CUDA/closed standards) are just deepening the divide between the GPU vendors, and moves us away from a single open standard.

goldenkey 13y ago
CUDA doesn't break any divide. It's not a closed standard at all. It's a platform specific standard. Nvidia has OpenCL support on their cards too, and its within 10% of the performance of CUDA. CUDA is just very optimized for the architecture, is all.
- foxhill 13y ago
  so how does one go about proposing additions or changes to CUDA? ironically, i've been able to get more performance from OpenCL than CUDA (mostly due in part to OpenCL's dual-source model, it allows me to compile runtime constants into kernels). CUDA is no more "optimised" than OpenCL. it's the same compiler that generates kernels. enqueueRead/Write calls end up being cudaMemcpy, etc.
  - goldenkey 13y ago
    You can compile runtime constants into CUDA too. CUDA has both a driver api AND the standard C toolkit. CUDA is a lot more optimized than OpenCL when you use it right. Many of the library functions perform better than there OpenCL equivalents or take different types. Having used both, I've got to say that OpenCL is craptastic compared to CUDA. One big example is the fact that you can't set a kernel-wide global in OpenCL, you have to pass it to the kernel every time as a buffer. In CUDA you can lookup the global by symbol, and set it, and it remains persistent. That means the CUDA kernel func will have a slightly smaller stack size from not having all these craptastic persistent args passed to the kernel every time. Also, instead of dereferencing a pointer that is passed as a kernel arg, you are directly using the global, again, code optimized. You haven't used CUDA enough probably. I understand how on the surface they appear similar. But wholly, CUDA is better thought out.
    - foxhill 13y ago
      it's not the standard programming model in CUDA. the library functions compile down to the same PTX, it's the exactly the same toolchain wether you use nvcc or clBuildProgram - if you could provide an example indicating otherwise, i'd very much like to see it. you most certainly can set a kernel-wide global in OpenCL, and it does not need to be a buffer object. and you don't need to re-set it between kernel invocations (this would be true even if it were a buffer object). OpenCL is certainly verbose, but honestly, given that you may have multiple implementations of it on the same machine, i don't really see how it could be done any simpler (at least from the C API perspective). i use CUDA and OpenCL every working day. it is literally what i am employed to do.

jevinskie 13y ago

The great thing about LLVM is its multitude of backends. I bet this Rust-to-PTX compiler would require just a bit of work to run using the R600 LLVM backend that targets AMD GPUs.

fdej 13y ago

> It's like writing C code that has to run on N different, immature, and mostly quirky compilers all with their own different subset of features, where N is completely unknown to you -- in fact N will grow over time after you release your application. In other words, it's like writing C code :-) (At least, if you require fancy features such as inline assembly, threads, string literals longer than 509 characters, 64-bit integers, ...)