3 ms·

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

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? 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 ago
  Exactly. 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 ago
  OpenCL 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 ago
    Maybe we could have a PTX frontend for SPIR-V. ;- )
nhaehnle 8y ago
You mean like HIP?[0] [0] https://github.com/ROCm-Developer-Tools/HIP https://github.com/ROCm-Developer-Tools/HIP
- claytonjy 8y ago
  Maybe! 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.

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 ago
Exactly. 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 ago
OpenCL 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 ago
  Maybe we could have a PTX frontend for SPIR-V. ;- )

nhaehnle 8y ago

You mean like HIP?[0] [0] https://github.com/ROCm-Developer-Tools/HIP https://github.com/ROCm-Developer-Tools/HIP

claytonjy 8y ago
Maybe! 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.