6 ms·
The problem of a heterogeneity in GPGPUs is that AMD and Intel can't make products that are competitive with NVidia. The "programming model" for "cross industri
by hctaw 6y ago
The problem of a heterogeneity in GPGPUs is that AMD and Intel can't make products that are competitive with NVidia. The "programming model" for "cross industries" (whatever those mean, the whole naming of this project is weird) aren't particularly deep moats if there were competitive solutions at lower prices.
- shmerl 6y agoAMD GPUs are better than Nvidia for that - they had async compute way longer. I thought the problem was CUDA lock-in and lack of a nice programming model using something modern like Rust may be.
- volta83 6y ago> AMD GPUs are better than Nvidia for that Better in what sense? > they had async compute way longer What is that?
- nynx 6y agorust-gpu (https://shader.rs https://shader.rs) is a spirv backend for Rust. It's early days, but already really promising. In my opinion, applying a good package manager (cargo) and a good language (rust) to gpgpu and rendering could result in great things.
- shmerl 6y agoYeah, that could be interesting. But it's still the shader approach, you just write shaders in Rust here. May be some other model can be designed that's nicer. CUDA isn't really using shader paradigm, right?
- nynx 6y agoCompute shaders are already supported and I believe support for opencl kernels, which are essentially expanded compute shaders, is on the long-term roadmap.
- oivey 6y agoBy async compute, do you mean something different than what CUDA streams expose? AMD’s compute cards have generally been worse than Nvidia’s as far as I know.
- shmerl 6y agoI mean actual hardware capabilities. AMD GPUs were ahead in that. See: http://developer.amd.com/wordpress/media/2012/10/Asynchronous-Shaders-White-Paper-FINAL.pdf http://developer.amd.com/wordpress/media/2012/10/Asynchronou...
- my123 6y agoWere. AMD totally squandered their advantage that they had with launching GCN early through an absolutely awful software stack.
- shmerl 6y agoRDNA 2 only improved on the above. Nvidia were and remain a dead end with CUDA lock-in, but I agree that there should be more combined efforts to break it.
- my123 6y agoLol? ROCm is a mess. It's awful. And it is not even supported on RDNA and RDNA2. They even dropped Polaris support last month so that it's only supported on Vega. And that's very much not a high quality GPU compute stack, sorry... CUDA isn't a dead end and isn't going away any time soon.
- shmerl 6y agoI was talking about hardware, not about ROCm. I said above, GPU compute could benefit from a nice programming model with a modern language. That will dislodge CUDA lock-in for good. CUDA isn't dead, but there should be a bigger effort to get rid of it because it's not a proper GPU programming tool but rather a market manipulation tool by Nvidia.
- Jhsto 6y agoThen again CUDA is pretty accessible language to program SIMD machines. I am bit sceptic if most people would recognise subjectively well-done SIMD language (lets say from correctness and performance standpoint). The programming model for SIMD is inherently parallel with exceptions for sequential code, which is pretty much the exact opposite of the programming you do on the CPU side. I'd somehow imagine most people would not find that modern at all, or alternatively, it would not be the language with "product market fit" since it's less likely to catch on. AMD or Intel may have a "better" language in some sense, but it seems most people prefer familiarity with what they already know.
- shmerl 6y agoCUDA is still stuck with Nvidia only. So improving on that and on the language itself is clearly an open item.
- Jhsto 6y agoWell, oneAPI can be used to do that. This submission is most likely in reference of a post a few days ago [1]. Here, PTX which CUDA targets is retargeted into SPIR-V which is ran atop oneAPI [2]. [1]: https://news.ycombinator.com/item?id=26262038 https://news.ycombinator.com/item?id=26262038 [2]: https://spec.oneapi.com/level-zero/latest/index.html https://spec.oneapi.com/level-zero/latest/index.html
- moonbug 6y agobut almost no one codes to the CUDA driver api.
- marmaduke 6y ago> I am bit sceptic if most people would recognise subjectively well-done SIMD language (lets say from correctness and performance standpoint) I found ISPC (https://ispc.github.io https://ispc.github.io) to be a little easier to work with than CUDA, for SIMD on CPUs, as it sits a bit in the middle of the CUDA and regular C models. Interop can work via C ABI i.e. trivial, it generates regular object files, and so on.