You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm really excited to see the maturity of the GPU support for Julia, particularly the speed of a working oneAPI implementation while everyone else (RAJA, Kokkos, etc) are still working on getting their implementations working. However, I am surprised that each GPU vendor lib is separate and has it's own slightly different API - this makes life more difficult in the Exascale multi-vendor HPC landscape. Is this being worked on or under consideration?
I've just started looking... so far the array types and broadcasting are nice and vendor independent, but the custom kernel and launch syntax varies a lot, in ways that I don't think are necessary. Sure the underlying runtimes have different names, and there are some subtle differences in SYCL ids vs CUDA ids, but HIP and CUDA are basically identical and I doubt very many people care about the differences in SYCL id naming or functionality.
The text was updated successfully, but these errors were encountered:
As you mention the array API is supposed to be vendor neutral.
For kernel programming, we're aiming for https://github.com/JuliaGPU/KernelAbstractions.jl to be that neutral API. It currently has support for CUDA.jl, and is used by several projects, but its dependency on Cassette.jl is problematic (but we expect to be able to get rid of that in the future). Alternatively, GPUArrays.jl has a similar DSL for vendor-neutral kernels, but we hope to rebuild that on top of KernelAbstractions.jl as soon as possible.
I'm really excited to see the maturity of the GPU support for Julia, particularly the speed of a working oneAPI implementation while everyone else (RAJA, Kokkos, etc) are still working on getting their implementations working. However, I am surprised that each GPU vendor lib is separate and has it's own slightly different API - this makes life more difficult in the Exascale multi-vendor HPC landscape. Is this being worked on or under consideration?
I've just started looking... so far the array types and broadcasting are nice and vendor independent, but the custom kernel and launch syntax varies a lot, in ways that I don't think are necessary. Sure the underlying runtimes have different names, and there are some subtle differences in SYCL ids vs CUDA ids, but HIP and CUDA are basically identical and I doubt very many people care about the differences in SYCL id naming or functionality.
The text was updated successfully, but these errors were encountered: