OpenCL.jl

OpenCL.jl copied to clipboard

Instead of targeting OpenCL C as an intermediate language I would be interested in trying to directly target SPIR. SPIR is proposed as a common IR for OpenCL and is currently supported by AMD and Intel. NVIDIA support is still outstanding because it needs atleast OpenCL 1.2, but it seems there is movement on that front. (CUDA 6 has stubs for OCL12 functions)

An example of how SPIR looks like can be found here: http://streamcomputing.eu/blog/2013-12-27/opencl-spir-by-example/ and the offical webpage is here: https://www.khronos.org/spir

Since Julia compiles to llvm IR and SPIR is an extension of that it might be feasible to extend the Julia compile process instead of creating a Julia to OpenCL C compiler.

@jakebolewski Do you think that might be a sensible project?

Some more information can be found here: http://www.slideshare.net/DevCentralAMD/pl-4051-yaxunliu especially mapping of OpenCL C types to llvm types

So for me it seems that the necessary steps would be:

• supply julia idioms for OpenCL function like get_global_id
  • http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053538.html
  • But the same problem has to be solved for OpenCL C
• Translate Julia to SPIR (llvm IR with certain restrictions)
• Use llvm's VerifySPIR stage to ensure validity
• obtain binary by either using llvm directly or via clBuildProgram("-x spir -spir-std=1.2", ....)
• then one should be able to use the program as currently in OpenCL.jl

Notes:

• use clang -S -x cl -fno-builtin -target spir -emit-llvm -c $filename to obtain SPIR for a OpenCL source file.

@vchuravy the compile to OpenCL C stuff was just an experiment and clearly OpenCL's LLVM IR support is the way forward. Even if Nvidia decides not to implement SPIR, the IR subset between NVVM and SPIR is conceptually very close so both backends could share a lot of the same code. You can also use Nvidia's OpenCL drivers to run compiled PTX kernels, so the runtime component could be written using OpenCL.

I think the steps you outlined are correct. Julia's code generation is really intertwined with its runtime component right now, you would essentially have to rewrite a totally new backend. Other issues I see are better compiler support for intrinsics that participate in type inference, but are passed directly through to the lowered AST (skiping inlining for instance). You would also have to track heap allocation and either throw an error or preallocate buffers before kernel invocation. Julia should be getting immutable array support this summer so this could help address this issue. Julia also has some numeric behavior that deviates from C (rounding, etc) that would have to be reimplemented in the backend.

I think the major blocker in attempting this is there is no good LLVM library support for Julia at the moment. Tackling that is a fairly large project in of itself.