There are some great replies to my comment - my original comment was too reductive. However, I still think that entrenching CUDA as the de-facto language for heterogeneous computing is a mistake. We need an open…
True. This is the big advantage of an open standard instead jumping from one vendors walled garden to another.
The problem with effectively supporting CUDA is that encourages CUDA adoption all the more strongly. Meanwhile, AMD will always be playing catch-up, forever having to patch issues, work around Nvidia/AMD differences,…
Intel's modern compilers (icx, icpx) are clang-based. There is an open-source version [1], and the closed-source version is built atop of this with extra closed-source special sauce. AOCC and ROCm are also based on…
What kind of performance is achieveable with some of the features that Vcc enables (true function calls, function pointers, goto), and what are some of the limitations? On GPU, function calls are much more expensive…
I wouldn't expect them to drop CUDA support, even if SYCL is a viable alternative: * The CUDA backend is mature, featureful, and significant effort has been invested into optimising it on Nvidia hardware. One does not…
A challenge with this is that all current AMD GPU support in SYCL compilers (DPC++ w/ Codeplay's oneAPI for AMD GPUs, and AdaptiveCpp), is built atop of ROCm / HIP. If AMD were to move away from ROCm, they would have to…
> The performance of any application on SYCL is currently quite poor. SYCL can get pretty much equivalent performance in Kernels to eg. CUDA. Try looking at SYCL performance papers on Arxiv. Eg. see [1]. That isn't to…
SYCL (closely related to oneAPI) isn't single-vendor-controlled. It's a Khronos open standard. If you take a look at the spec, you'll see contributions from various universities, Qualcomm, Huawei, Argonne, Altera, and…
> Why would you want OpenCL? OpenCL is stricter with the results of floating point operations, and makes different assumptions with respect to memory aliasing. Whether or not this is important the AI domain I don't…
SYCL isn't based on OpenCL. SYCL (SYCL-2020 spec) supports multiple backends, including Nvidia's CUDA, AMD's HIP, OpenCL, Intel's Level-zero, and also running on the host CPU. This can either be done with Intel's DPC++…
SYCL is gaining traction, especially in the HPC community since it can target AMD, Nvidia and Intel hardware with one codebase. A fun fact is the GROMACS (a major application for molecular dynamics, and big consumer of…
There are some great replies to my comment - my original comment was too reductive. However, I still think that entrenching CUDA as the de-facto language for heterogeneous computing is a mistake. We need an open…
True. This is the big advantage of an open standard instead jumping from one vendors walled garden to another.
The problem with effectively supporting CUDA is that encourages CUDA adoption all the more strongly. Meanwhile, AMD will always be playing catch-up, forever having to patch issues, work around Nvidia/AMD differences,…
Intel's modern compilers (icx, icpx) are clang-based. There is an open-source version [1], and the closed-source version is built atop of this with extra closed-source special sauce. AOCC and ROCm are also based on…
What kind of performance is achieveable with some of the features that Vcc enables (true function calls, function pointers, goto), and what are some of the limitations? On GPU, function calls are much more expensive…
I wouldn't expect them to drop CUDA support, even if SYCL is a viable alternative: * The CUDA backend is mature, featureful, and significant effort has been invested into optimising it on Nvidia hardware. One does not…
A challenge with this is that all current AMD GPU support in SYCL compilers (DPC++ w/ Codeplay's oneAPI for AMD GPUs, and AdaptiveCpp), is built atop of ROCm / HIP. If AMD were to move away from ROCm, they would have to…
> The performance of any application on SYCL is currently quite poor. SYCL can get pretty much equivalent performance in Kernels to eg. CUDA. Try looking at SYCL performance papers on Arxiv. Eg. see [1]. That isn't to…
SYCL (closely related to oneAPI) isn't single-vendor-controlled. It's a Khronos open standard. If you take a look at the spec, you'll see contributions from various universities, Qualcomm, Huawei, Argonne, Altera, and…
> Why would you want OpenCL? OpenCL is stricter with the results of floating point operations, and makes different assumptions with respect to memory aliasing. Whether or not this is important the AI domain I don't…
SYCL isn't based on OpenCL. SYCL (SYCL-2020 spec) supports multiple backends, including Nvidia's CUDA, AMD's HIP, OpenCL, Intel's Level-zero, and also running on the host CPU. This can either be done with Intel's DPC++…
SYCL is gaining traction, especially in the HPC community since it can target AMD, Nvidia and Intel hardware with one codebase. A fun fact is the GROMACS (a major application for molecular dynamics, and big consumer of…