UXL Foundation readying alternative to Nvidia's CUDA for this year
- Reference: 1711463115
- News link: https://www.theregister.co.uk/2024/03/26/uxl_foundation_cuda_alternative/
- Source link:
Announced last year, the [1]Unified Acceleration (UXL) Foundation is a group of companies operating under the aegis of the Linux Foundation to develop an open standard accelerator programming model for application realms, including, of course AI.
This would potentially make it a rival for Nvidia's software, such as its [2]CUDA platform, which is long established but designed to work with the company's own GPU accelerator hardware.
[3]
Rod Burns, chair of the UXL Foundation Steering Committee, told The Register : "In fact, the specification has been under development for a few years and has been released regularly over that time. This means we already have a mature specification for many of the fundamentals needed."
[4]
[5]
However, he added: "This work continues through 2024 through refinement and is led by the Specification Working Group within the foundation, we will make be aiming to ratify a spec release in Q4."
Beyond this, implementations of the spec have been under development for the past few years and are now being used by some developers to write code and target multiple vendors, Burns explained.
[6]
"Our goal this year is to continue to build out the vendor support for the libraries, add new features and follow best practices for open governance to deliver a specification fit for the whole community."
Meanwhile, [7]Reuters reported that the UXL Foundation technical steering committee is preparing to "nail down" technical specifications in the first half of this year, and that these will be refined to a "mature state" by the end of the year.
The project has backing from a number of heavy-hitters, with steering members of the UXL Foundation including Arm, Intel, Google Cloud, Qualcomm, Fujitsu, and VMware.
[8]
Intel is the significant one here as the UXL Foundation effort is effectively an evolution of the [9]oneAPI initiative , its existing unified programming model aimed at providing a common experience for developers across accelerator architectures.
[10]Tiny Corp launches Nvidia-powered AI computer because 'it just works'
[11]Nvidia: Why write code when you can string together a couple chat bots?
[12]How to run an LLM on your PC, not in the cloud, in less than 10 minutes
[13]Nvidia talks up local AI with RTX 500, 1000 Ada mobile GPUs
The heterogeneous support is intended to include not only CPUs and GPUs, but other accelerators, including FPGAs, although recent interest in AI acceleration has largely focused on GPUs.
"The increasing demand for data-intensive workloads has led to proliferation in the use of GPUs, and most recently the emergence of LLM-based AI applications has created an explosion in GPU usage," Burns wrote at the time of UXL's announcement in September.
"The challenge we are facing right now is that, where Linux and GNU transformed the software stack for CPUs using open source and standards-based projects, the GPU software stack is still quite new and standards are in some areas, especially AI, still being defined," he added.
Burns is also VP of Ecosystem at Codeplay Software. Codeplay was [14]acquired by Intel in 2022 for its skills in SYCL, a cross-platform abstraction layer used in oneAPI that allows developers to program for heterogeneous architectures in C++ code.
Of course, challenging Nvidia's dominance may not be so easy. UXL eventually aims to support Nvidia hardware and code, yet many customers have already invested large sums of money into projects based on the Nvidia's software stack and may see little reason to change.
AMD, for example, was said to be working to bring binary compatibility with Nvidia's CUDA APIs to its own ROCm software so that applications written for Nvidia would run on its hardware without modification. According to [15]Phoronix , however, AMD has not released it as a product and has now discontinued funding the project. ®
Get our [16]Tech Resources
[1] https://uxlfoundation.org/
[2] https://www.theregister.com/2022/05/02/nvidia_open_standards/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZgL-JiHeYyCbgUbBYCbkPwAAABE&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZgL-JiHeYyCbgUbBYCbkPwAAABE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZgL-JiHeYyCbgUbBYCbkPwAAABE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZgL-JiHeYyCbgUbBYCbkPwAAABE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://www.reuters.com/technology/behind-plot-break-nvidias-grip-ai-by-targeting-software-2024-03-25/
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZgL-JiHeYyCbgUbBYCbkPwAAABE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[9] https://www.oneapi.io/
[10] https://www.theregister.com/2024/03/25/tiny_corp_amd_nvidia/
[11] https://www.theregister.com/2024/03/19/nvidia_why_write_code_when/
[12] https://www.theregister.com/2024/03/17/ai_pc_local_llm/
[13] https://www.theregister.com/2024/02/26/nvidia_ai_pc_gpus/
[14] https://community.intel.com/t5/Blogs/Products-and-Solutions/Software/Intel-to-Acquire-Codeplay-Software/post/1389054
[15] https://www.phoronix.com/review/radeon-cuda-zluda
[16] https://whitepapers.theregister.com/
AMDs software has been crap, to the extent of fundamental bugs in the fft lib being reported and unfixed for 2years.
They can't get onboard with Intel's API if Intel are competing with AMD for graphics card sales.
And nobody is going to get behind an open standard that doesn't give them the advantage everyone else implementing the standard, so it becomes a box tick 'opencl support(*)' in the same way that Windows 'supported' OpenGL and POSIX.
* for minimum values of support
> And nobody is going to get behind an open standard that doesn't give them the advantage everyone else implementing the standard
Erm, Vulcan? It was obvious to everyone that multiple diverging standards in the graphics space was hurting everyone.
What you say may be true for AI compute at the moment with there being still rapid development, but I don't think it will be long before the software stack starts to become somewhat commoditised and both developers and manufacturers will want converge on something to avoid the ongoing cost of maintaining it. For NVidia, CUDA is a means to an end and that end is selling hardware. It's only really popular now because it is the only big game in town and people have invested in it.
Once something useful emerges that is cross-platform, people will move to it in droves. Vulcan was like that. It was in the pipeline for quite a while, then once it became mature, everyone important jumped onto it.
Is very likely this will fail, like many others before
And the worst part is that I'd love to see an alternative to CUDA to exist, but our desires should not impede an impartial analysis...
The most glaring example of past initiatives failing is OpenCL. Between 1.0 and 2.2 it was painfully slow, so slow in fact, that Apple deprecated it, after all the work they did to spearhead it, and integrat it as a frist class citizen in OSX/MacOS (for instance, one could use Grand Central dispatch to issue OpenCL tasks as easily for OpenCL as for CPU).
And then came the clusterFSCK that was OpenCL 3.0, where the mandatory baseline is OpenCL 1.2 (that is, in fact, a regression) and then everything else is OPTIONAL. Which means, is super hard to write hardware agnostic code in OpenCL 3.0, as not all functions will be supported by all manufacturers.
And remember, beyond AMD, Intel and nVidia, there is Qualcomm (Adreno), ARM (Mali), PowerVR, VIA (as S3), and the Only-China duo of Imaginnation Technologies (similar but not equal to PowerVR) and MooreThreads. Pleanty of hardware to choose if you want to write OpenCL code. And please also remmeber GPU Accelerated code is not only used for ML/AI, or CFD, or HPC, but also for day to day tasks (Like calculating indexes and hash codes in databases). Also, remmeber that many of the "Lesser" GPU architectures are used in ARM servers
Similar examples exist with things like SYCL, and, as the previous comentor wrote, AMD doing FOSS GRaphics and CUDA-Killers as knee-jerk reactions and changing things every few years... AMD has been bussy changing their "CUDA Killer" architecture (and the Accelerated Graphics one too) every few years. Close To Metal, Mantle, Stream, GPUOpen, HIP, ROCm... ¿Does any one of those ring a bell?
Instead of AMD's engineers heeding the suba divers advice:
Stop-Think-Act. If I can do that 500m inside a Cavern, why AMD's fellow engineers can not do it sitting in a conference room is beyond me...
So, TLDR: While I would like to have an alternative to CUDA, past experience says that these kind of initiatives fail, Is likely that this one will fail as well.
It is and has been for some time obvious that AMDs ROCm is a failure. After Lisa Su came aboard in 2015 or so and gutted the Fusion and HSA program to start over with ROCm it has been a disaster. Yes she has shepherd in Ryzen/EPYC, Infinity Architecture and Xilinx. AMD hardware is second to none in the X86-64 world. But their software work is very sub-par. I recently stated on Phoronix that at this point AMD should just abandon ROCm and adopt Intel’s oneAPI and their entire compute stack. Maybe UXL can be the bridge in which AMD walks away from ROCm and cuts their losses.