What does HackerNews think of ZLUDA?

> I don't think you understand just how insanely difficult it is to break into that market.

You're right, I have no clue nor have I ever tried myself.

> Even with apple money or something like that, it's a losing prospect because in the time it'll take you to get up and off the ground (which is FOREVER) your competition will crush you.

This I find hard to believe, do you have a source or reference for that claim? Companies with that amount of cash are hardly going to be crushed by competition be it direct or indirect. Anyway, I'm talking more about the Intels and AMDs of this world.

We have very lacklustre efforts from players I won't name with their Zluda library (https://github.com/vosen/ZLUDA) which I got REALLY excited about, until I read the README.txt. Four contributors, last commit early 2021.

Why, oh why, is it this bad?

From the Arch wiki, which has a list of GPU runtimes (but not TPU or QPU runtimes) and arch package names: OpenCL, SYCL, ROCm, HIP,: https://wiki.archlinux.org/title/GPGPU :

> GPGPU stands for General-purpose computing on graphics processing units.

- "PyTorch OpenCL Support" https://github.com/pytorch/pytorch/issues/488

- Blender re: removal of OpenCL support in 2021 :

> The combination of the limited Cycles split kernel implementation, driver bugs, and stalled OpenCL standard has made maintenance too difficult. We can only make the kinds of bigger changes we are working on now by starting from a clean slate. We are working with AMD and Intel to get the new kernels working on their GPUs, possibly using different APIs (such as CYCL, HIP, Metal, …).

- https://gitlab.com/illwieckz/i-love-compute

- https://github.com/vosen/ZLUDA

- https://github.com/RadeonOpenCompute/clang-ocl

AMD ROCm: https://en.wikipedia.org/wiki/ROCm

AMD ROcm supports Pytorch, TensorFlow, MlOpen, rocBLAS on NVIDIA and AMD GPUs: https://rocmdocs.amd.com/en/latest/Deep_learning/Deep-learni...

RadeonOpenCompute/ROCm_Documentation: https://github.com/RadeonOpenCompute/ROCm_Documentation

ROCm-Developer-Tools/HIPIFY https://github.com/ROCm-Developer-Tools/HIPIFY :

> hipify-clang is a clang-based tool for translating CUDA sources into HIP sources. It translates CUDA source into an abstract syntax tree, which is traversed by transformation matchers. After applying all the matchers, the output HIP source is produced.

ROCmSoftwarePlatform/gpufort: https://github.com/ROCmSoftwarePlatform/gpufort :

> GPUFORT: S2S translation tool for CUDA Fortran and Fortran+X in the spirit of hipify

ROCm-Developer-Tools/HIP https://github.com/ROCm-Developer-Tools/HIP:

> HIP is a C++ Runtime API and Kernel Language that allows developers to create portable applications for AMD and NVIDIA GPUs from single source code. [...] Key features include:

> - HIP is very thin and has little or no performance impact over coding directly in CUDA mode.

> - HIP allows coding in a single-source C++ programming language including features such as templates, C++11 lambdas, classes, namespaces, and more.

> - HIP allows developers to use the "best" development environment and tools on each target platform.

> - The [HIPIFY] tools automatically convert source from CUDA to HIP.

> - * Developers can specialize for the platform (CUDA or AMD) to tune for performance or handle tricky cases.*

There is ZLUDA, based on oneAPI if I recall correctly: https://github.com/vosen/ZLUDA

On some OpenCL implementations (as in, the ones supporting the SPIR-V OpenCL profile instead of just OpenCL C), this is possible.

Intel has a cleaned up variant of OpenCL for the purpose of running SPIR-V binaries called oneAPI L0, and Zluda can run on top of it. https://github.com/vosen/ZLUDA

AMD used to support SPIR in their driver, but they removed support for that in 2018. As such, you won’t get anything useful out of that one on AMD GPUs.