Right now it’s “buy GPUs at any cost”. If things slow, there will be a chance for these customers to consider how to optimize this cost. NVIDIA can’t sit on its laurels like Intel did with x86.
Right now it’s “buy GPUs at any cost”. If things slow, there will be a chance for these customers to consider how to optimize this cost. NVIDIA can’t sit on its laurels like Intel did with x86.
First, it's the classic chicken and egg problem. Why would you invest in a CUDA alternative when you're going to be using nvidia hardware anyway?
Second, something can be not impossible but still quite difficult. As AMD and Intel have shown, creating a GPGPU API for your hardware that people want to use is not a trivial task and to date have not managed to do it.
Lastly this must just be differences in our experiences with cooperate management, because mine has been that in general they would always prefer to spend on stuff over headcount if said stuff reduces the headcount required.
So most probable end result is that we end up with multiple competing alternatives all with their own vendor lock ins. And general public might be lucky to get one or two options.
People do not scale.
Compared to the problem of developing a new cutting-edge GPU, building a CUDA compatibility layer is a much smaller problem. Hire the author of ZLUDA, throw a small team at it, and have a legal department on standby. And separately, there'd also be value in some source-translation projects to help people migrate to some better native framework.
Also as for AMD, as I understand, they are unwilling to make ML libraries for consumer-grade GPUs and GPUs built into CPUs.
The reverse approach, of trying to entice people to move from CUDA to a different library and switch GPUs at the same time, has been tried repeatedly and has not yet succeeded. Trying something different seems warranted.