Hi!
I verified that I can greatly improve my satellite simulator if I use the GPU processing of some parts. It will be a huge change. Since I do not want to lock this feature for NVIDIA users only (I am Mac user, so no nvidia here also…), then I need to use OpenCL.
Question for those who are using OpenCL in Julia: is it stable and maintained for a long-term project? What problems should I expect?
I’ve played little with OpenCL and it worked well, but if you want to use advanced algorithms I cannot say a word. For me, using ArrayFire has been very useful, maybe is useful for you too.
I can certainly appreciate the desire to not be locked into NVIDIA. I am the same boat with Mac. I require DifferentialEquations.jl’s ensemble GPU support which, as far as I’m aware, only works on NVIDIA GPUs. My solution is to setup a cloud VM and connect to a remote process in the VM with JUNO. It works very well.
OpenCL is not the only option if you’re an AMD GPU owner; Julia has a work-in-progress AMDGPU computing stack which aims to mirror the functionality available in Julia’s CUDA stack. While we only currently support Linux as an OS, I have an open PR to support Macs and Windows machines via the OpenCL runtime (but without having to write OpenCL C kernels).
GPUifyLoops needs support for AMDGPU for that to work. But that could be a nice Julia Lab project 
I like OpenCL because people can use in both systems. I also do not mind writing kernels in C. I did some tests and the OpenCL support seems pretty solid!
Agreed, which is why I opened a PR for this a few months back: [WIP] Add support for ROCm by jpsamaroo · Pull Request #64 · vchuravy/GPUifyLoops.jl · GitHub
I just need to wire a few more things up and get CI to pass 
Most people do. Taking that into account, OpenCL is currently not well supported by any Julia package (Transpiler.jl is dead), and you should use CUDAnative/CuArrays or the ROCM equivalent. If you care about portability, restrict your application to generic array expressions (map, reduce, broadcast). That ensures you can easily switch between platforms by swapping the array type. If you need custom kernels, you can do so using GPUif Loops.
But what is my option for AMD? IIUC CLArrays.jl does not work in Julia 1.0.
See my initial post above for links; AMDGPUnative is the sister package to CUDAnative, and ROCArrays is the sister package to CuArrays. We’re actively working on keeping the AMD sister packages closely in sync with the CUDA packages so that users get a similar, seamless experience whether they have an AMD or an NVIDIA GPU available (that’s the goal, at least ).
Excellent! I haven’t considered using it because the README says that it is not ready for usage yet.
True, the AMDGPU stack is still in the “experimental” stages. However, if you are able to support the CUDA stack in SatelliteToolbox by using common array operations and generic functions, then I will make sure that the AMD stack works properly on SatelliteToolbox as well. In other words, write things generically, and I’ll do the work to ensure we support your package and users
The idea is awesome and I am very glad that this can work like that! However, I currently do not have a single NVIDIA card to test. I was expecting to develop to AMD and hope that everything would work with NVIDIA 
What OS and GPU do you have available?
macOS and AMD Radeon only.
What about https://github.com/JuliaGPU/OpenCL.jl package? How does it fit into this discussion?
OpenCL.jl doesn’t give you much in the way of higher-level abstractions. IMO the biggest hurdle for designing such an API is lack of a good kernel synthesis mechanism. While every other GPU library can compile Julia functions to some device IR, OpenCL requires cobbling together a C kernel with string concatenation because that’s the lowest common denominator amongst different implementations.
If one were to successfully revive CLArrays, the easiest approach would be to get SPIR-V compilation working via GPUCompiler’s OneAPI path and plumbing that into OpenCL.jl. This would dramatically limit what devices are supported, but anything is still > 0. I looked into this a bit over the holidays, but it’ll likely be a non-trivial effort because of how differently OpenCL.jl (and OpenCL in general) is structured compared to the other GPU compute libraries.
I am using nvidia rtx-2080ti, but I find it is not very friendly to linux. The properity driver and cuda works fine, but since it is not open source, sometimes it lead to broken head of linux.
I actually prefer opencl, open source is always better, my next computer will be amd video cards. I hope your project keep going and reach the goal.