6 ms·
That would have been hard to write out and genuinely support a couple years ago, when NVidia ruled the top-of the line as well as the best value-for-money most
by LeifCarrotson 9y ago
That would have been hard to write out and genuinely support a couple years ago, when NVidia ruled the top-of the line as well as the best value-for-money most of the way down the chain. It was a hefty hit to your framerate or your wallet to support AMD.
But these days AMD is a serious contender at all levels! If the performance or value isn't actually in AMD's favor, it's near enough to be undetectable outside of a benchmark, and very easy to support the good guys.
- chrisseaton 9y ago> very easy to support the good guys But AMD doesn’t run CUDA? Is it very easy to switch a stack relying on CUDA to OpenCL? I don’t think so.
- zdw 9y agoAMD's ROCm suite has a tool for converting CUDA to C++ code: https://github.com/ROCm-Developer-Tools/HIP https://github.com/ROCm-Developer-Tools/HIP How well it works is likely codebase and application dependent.
- frozenport 9y agoHere was my experience. Everything in ocl ended up slower, with 30%+ longer (walltimes) on nvidia hardware. Also some problems with floating point precision. Real problem was there was no business case to switch because we could always make customers eat the cost of taking nvidia gpus. The added code complexity was not worth it - we originally did it as NRE for a big client who wanted OEM capabilities to our IP.
- katastic 9y agoOpenCL is slower than CUDA, but it's not the end of the world.
- mangix 9y agogot a reference?
- unfamiliar 9y agoThat is simply not true.
- biafra 9y agoPlease be more specific. What is not true? That it is slower or that this is not the end of the world?
- katastic 9y agoWow, people are butthurt. It's a wildly known fact in the industry. A simple google search for benchmarks or a PDF like this would have satisfied them. But they didn't want the truth they wanted to be butthurt. https://arxiv.org/ftp/arxiv/papers/1005/1005.2581.pdf https://arxiv.org/ftp/arxiv/papers/1005/1005.2581.pdf In basically every chart and graph, OpenCL is slower. OpenCL has a higher level of abstraction, so it's got a higher penalty for it. But, you get cross-platform support. nVidia doesn't optimize for OpenCL either because they don't want you to use it over their own competing framework. But 'dats cool, keep downvoting, guys. Sources aren't real if you can downvote 'em enough. God, I love Hacker News.
- grzm 9y agoWould you kindly raise the level of discourse here? You have useful information, so thanks for sharing it. But please leave the swipes and complaints about downvotes and HN members out of it. It worsens discussion and is against the guidelines. You’ll likely receive downvoted for that, more than anything else.
- sli 9y agoThis reddit-style, highly emotional commenting is not terribly welcome on HN.
- frozenport 9y agoYea it is. Take a look at fft performance across cufft and the ocl equals on same nvidia hardware.
- mrmondo 9y agoI’ve been using OpenCL for some neutral net image optimisation recently, I’ve actually found it very efficient (citation obviously needed), I personally welcome the competition of AMD and it does seem like Nvidia is digging its own grave (not that I think it’ll die).
- wyldfire 9y agoI don't think it's that hard, but it depends maybe a bit on how long your codebase has evolved through CUDA.
- nl 9y agoThere are zero DL frameworks that support AMD cards as a primary target. Most have some kind of branch or patchset with OpenCL support. The problem is that they aren't great. If you need any new layers there is no support. There is nothing like CuDNN so you don't get the high speed convolutional kernels. It's great to blame developers for supporting NVidia, but the thing is NVidia are great to work with. They dedicate large teams to deep learning support (not like the 2 or 3 part time Devs AMD does), and they publish good research and tutorials. AMD does nothing like this.
- tgtweak 9y agoAmd had always had first class support for openCL, cuda is Nvidia proprietary and although Nvidia "supports" OpenCL, it's quite bad. Issue #22 on tensorflow is regarding openCL support. AMD has done some interesting work on HCC (a more proper gpgpu compiler approach with llvm base) and that is showing promise. See here: https://instinct.radeon.com/wp-content/uploads/sites/4/2017/11/1-848x700.jpg https://instinct.radeon.com/wp-content/uploads/sites/4/2017/... Additionally, they support cuda decompiling to HIP which is an intermediary that can be built to target Nvidia (via nvcc) or amd (via HCC). Nvidia has built a lot of tooling for DL, such as cudnn, and the new Tesla cards have dedicated silicon for tensor calculation. Amd does have a cudnn equivalent called MlOpen. They have also ported caffe via HIP and it works well. Work is being done by amd right now to torch, mxnet and tensorflow to add support for amd hardware with minimal burden to the maintainers of these projects. You can read about some of the DL toolkits available here: https://instinct.radeon.com/en/6-deep-learning-projects-amd-radeon-instinct/ https://instinct.radeon.com/en/6-deep-learning-projects-amd-... I think it's particularly bad form on behalf of everyone in the DL framework and library world to cator only to Nvidia and cuda, and that they very much walked into this shake down with open arms. The original comment is correct in that contributing support for OpenCL (which works on mobile too) will alleviate this to a fair degree. It's one of those things where the more momentum is behind it, the more device manufactures will focus on ensuring their opencl compiler is building properly optimized kernels for their hardware. Start contributing to OpenCL or adding hip support to existing projects and we'll see some viable alternatives pop up from not only AMD, but players like Qualcomm and Samsung.