8 ms·
It's unfortunate, but the reality is it would take an act of god to unseat CUDA at this point.
by Miraste 4y ago
It's unfortunate, but the reality is it would take an act of god to unseat CUDA at this point.
- tambourine_man 4y agoUnless someone beats them in the hardware front. GPUs that are 30-50% faster (or just as fast but 30-50% cheaper). I could see Apple and AMD, working with TSMCs latest node, stepping up to the challenge.
- ceeplusplus 4y agoNo way 30-50% is enough. You need 2x at least, if not more. There is a deep rooted ecosystem of CUDA apps. You would need to have at least 2-3 generations of 2x lead to get people to switch.
- bobajeff 4y agoThat or they could just open their GPU cores to direct programming instead of locking it behind some API.
- amluto 4y agoThis depends on the degree to which the underlying hardware remains compatible across generations. nVidia can sell monster GPU systems today to run 5-year-old CUDA code faster without any recompilation or other mandatory engineering work. I don’t know whether this is possible with direct hardware access.
- PaulHoule 4y agoIntel's OneAPI (rebranded OpenCL) can allegedly do this. It also claims to do this across radically different architectures like FPGA and all I can say to that is "I find that very hard to believe"
- buildbot 4y agoYeah it is in practice not really true. Maybe after hacking the code you can watch it compile for _days_ and then perform probably worse than a GPU without extreme tuning, which removes the point anyway.
- pjmlp 4y agoRebranded SYCL, if it was rebranded OpenCL, it wouldn't even be worth a 2nd look.
- greenknight 4y agoDepends... sometimes its built specifically to kernels. One common instance is, blender's Cycles renderer. Every time there is a new NVIDIA GPU. It needs to be recompiled to support it. Sometimes that also requires a new CUDA version to be able to do it. CUDA versions over the years have deprecated different operations and what not.
- wmf 4y agoThat's a "did you just tell me to go fuck myself?" solution. It didn't work for AMD and it won't work for anyone else. Developing a CUDA-to-GPU compiler and runtime stack is an immense amount of work and customers or "the community" can't afford it. Although for completeness I'll note that Intel's GPU architecture is documented: https://01.org/linuxgraphics/documentation/hardware-specification-prms https://01.org/linuxgraphics/documentation/hardware-specific...
- nicoburns 4y agoCould Intel just implement CUDA support? That would certainly be a huge task, but Intel aren’t have the resources for that.
- paulmd 4y agoThe GPU Ocelot project did exactly that at one point. It's probably a legal minefield for an organized corporate entity though. https://gpuocelot.gatech.edu/ https://gpuocelot.gatech.edu/
- TomVDB 4y agoOne of the big attractions of CUDA is not just the core (programming, API, compiler, development tool) but also the libraries (cuDNN, FFT, cuSignal, … It’s a very long list). These libraries are usually not open source, and can thus not be recompiled even if you have core CUDA support.
- Aromasin 4y agoIntel doesn't implement CUDA, but they're working on a CUDA to DPC++ (their parallel programming language) migration tool to make the jump less painful. I've tested some of the NVIDIA samples with it and it seems to do the vast majority of the grunt work, but there are still some sections where refactoring is required. You can find it in the OneAPI base toolkit.
- doppioandante 4y agoThere is ZLUDA, based on oneAPI if I recall correctly: https://github.com/vosen/ZLUDA https://github.com/vosen/ZLUDA
- VHRanger 4y agoVulkan compute might, over time, take root. The fact that a similar API can be used for training on servers, inference from laptops to phones, is an appealing proposition Best part: most devices have decent vulkan drivers. Unlike openCL.
- pjmlp 4y agoOnly on Khronos dreams, its experience is even worse than OpenCL.