4 ms·
The CUDA tax is serious, however in this case it is mostly the fault of competing vendors that there is no CUDA or almost-CUDA implementation, since it is fairl
by microcolonel 8y ago
The CUDA tax is serious, however in this case it is mostly the fault of competing vendors that there is no CUDA or almost-CUDA implementation, since it is fairly high-level, unlike an ISA and the accompanying treadmill of patented features which move the expiry date of the "platform" 20 years into the future every couple years.
- claytonjy 8y ago> it is mostly the fault of competing vendors that there is no CUDA or almost-CUDA implementation I very much agree, but I also don't have the skills or knowledge to say what kind of effort it takes to build such a language/toolchain. It seems like such an obvious opportunity for AMD, and has for so long, could it be less incompetence and more engineering difficulty and/or adoption struggles? I know I've seen talk of CUDA-killers around these parts before, would love to hear more details from people more familiar with this stuff.
- microcolonel 8y ago> I know I've seen talk of CUDA-killers around these parts before, would love to hear more details from people more familiar with this stuff. From the market perspective, it seems to me that a "CUDA killer" would not actually help. I think we need a free CUDA toolchain.
- claytonjy 8y agoI think that's roughly what I meant; I'd like to see AMD dump resources into making a fully open, compatible-with-all-modern-GPUs toolchain to directly compete with and replace the CUDA one. For all I know, they already are? Heck even a non-open, AMD-specific toolchain would probably be great for consumers, but an open, cross-compatible toolchain would be even better for us, and might be better for AMD as well by allowing non-AMD-employed experts to contribute.
- jcranmer 8y ago> I think that's roughly what I meant; I'd like to see AMD dump resources into making a fully open, compatible-with-all-modern-GPUs toolchain to directly compete with and replace the CUDA one. For all I know, they already are? There's OpenCL. Except OpenCL performance is worse than CUDA performance on NVidia, so anyone using NVidia's hardware (essentially, everyone) pretty much wants to use CUDA instead.
- claytonjy 8y agoExactly. We need something roughly on-par with CUDA, though it could be a bit below CUDA on Nvidia cards if it allows near-CUDA performance on non-Nvidia cards. Making all this easier to install/use/deploy could go a long way to winning user over, too; I'll gladly let a model run longer if I spent a lot less time getting things setup properly. The integration part is no small amount of work; it needs to be so smooth that I don't have to care what kind of card I have, and can run TF/Pytorch/etc. models in the same way regardless.
- pjmlp 8y agoOpenCL made the mistake of being C only in the beginning while CUDA embraced C, C++ and Fortran, plus any language that would bother to write a PTX backend. SPIR was too little, too late.
- microcolonel 8y agoMaybe we could have a PTX frontend for SPIR-V. ;- )
- nhaehnle 8y agoYou mean like HIP?[0] [0] https://github.com/ROCm-Developer-Tools/HIP https://github.com/ROCm-Developer-Tools/HIP
- claytonjy 8y agoMaybe! To be a success, I think it needs to integrate with TF/Pytorch/etc. at least as seamlessly as CUDA does and be clearly competitive in benchmarks of common DL stuff (e.g. training on Imagenet). It's not clear to me it's even possible to take a TF model I have and use this to run it on an AMD card.
- orbifold 8y agoThere is a free CUDA tool chain it is called clang, there just isn’t a runtime library or backend for any other architecture except NVIDIA at the moment although I think AMD is working on it.