3 ms·
I think this situation can only be fixed by moving up into languages that compile to vendor specific GPU languages. Just treat CUDA, openCL, vulkan compute, met
by rowanG077 5y ago
I think this situation can only be fixed by moving up into languages that compile to vendor specific GPU languages. Just treat CUDA, openCL, vulkan compute, metal compute(??) etc. as the assembly of graphics cards.
- T-A 5y agohttps://www.oneapi.io/ https://www.oneapi.io/
- snicker7 5y agoCurrently only supported by Intel.
- T-A 5y agohttps://www.codeplay.com/solutions/oneapi/for-cuda/ https://www.codeplay.com/solutions/oneapi/for-cuda/ https://www.urz.uni-heidelberg.de/en/newsroom/oneapi-academic-center-of-excellence-established-at-the-heidelberg-university-computing-centre-urz https://www.urz.uni-heidelberg.de/en/newsroom/oneapi-academi...
- hobofan 5y agoBarely anyone is writing CUDA directly these days. Just add support in PyTorch and Tensorflow and you've covered probably 90% of the deep learning market.
- hprotagonist 5y agoand ONNX.
- pjmlp 5y agoThat is just part of the story. CUDA wiped out OpenCL, because it went polyglot as of version 3.0, while insisting that everyone should write in a C dialect. They also provide great graphical debugging tools and libraries. Khronos waited too long to introduce SPIR, and in traditional Khronos fashion, waited for the partners to provide the tooling. One could blame NVidia, but it isn't as the competition has done a better job.