3 ms·
PyTorch would probably be the easiest way to get started there, it should give you a NumPy style handle into high-level objects. As far as low-level, OpenCL ha
by paulmd 4y ago
PyTorch would probably be the easiest way to get started there, it should give you a NumPy style handle into high-level objects.
As far as low-level, OpenCL has always had a horrendous amount of boilerplate just to get started, CUDA is a little better. One thing that can help is Thrust framework on CUDA, which attempts to provide a C++ STL-style interface to GPU operations. I am not saying it's super performant but especially it can give you a place to start and handle some of the boilerplate automatically.
In classic AMD fashion there is a me-too copy that hasn't been updated in like 5+ years, probably was some intern's summer project or some employee's resume-driven-development thing and AMD has just always left this trail of abandoned projects in their wake.
https://thrust.github.io/ https://thrust.github.io/
https://hsa-libraries.github.io/Bolt/html/ https://hsa-libraries.github.io/Bolt/html/
But basically what this is going to look like is a main function that sets everything up, and then a __global__ kernel launch that does the actual computation. You probably will have a 1D or 2D grid of threads, where each thread gets a threadIdx.x and threadIdx.y and that determines the row/column of elements they compute.
For Thrust/Bolt you can do a cheat implementation by zipping the thread position into a (int x, int y) pair driven by count_iterators, and then having a functor which takes the (x,y) and does the computation. Or the "true" implementation would be an accumulate-reduce operation I guess, but, frankly the STL-style stuff starts to fall apart pretty quickly and it just ends up being a convenient way to hook up the lower-level code without having to worry about too much boilerplate.
- roenxi 4y ago> PyTorch would probably... Less obvious than you might believe. I suspect PyTorch doesn't support any AMD GPU that are more than ~5 years old, because PyTorch is currently ROCm 5.0 and that only supports Vega 2.0 and up [0]. This is that thing about AMD not doing a great job of supporting consumer GPU. There was a window where PyTorch allegedly supported ROCm 4.x and therefore my GPU, but I expect that was a misdirection since AMD never seemed to make this stuff work. [0] https://docs.amd.com/bundle/ROCm-Release-Notes-v5.2/page/About_This_Document.html https://docs.amd.com/bundle/ROCm-Release-Notes-v5.2/page/Abo...
- paulmd 4y agoYeah, I haven't done PyTorch on AMD hardware and I guess that's not surprising with the support story. I've commented elsewhere about AMD building the whole ecosystem around everyone working/distributing source and compiling only at runtime, and how I think that's kind of a nonstarter for commercial operators or any sort of hobbyists/etc. But generally it just seems like AMD is utterly uninterested in targeting anyone but HPC. You see the guy in this thread posting the "but look at all 2 of the supercomputers using AMD GPUs!" (and I've seen the same talking point brought up in other discussions too) and that's the thing, is, ROCm is exactly the minimum effort they need to get those HPC wins and not a developer-hour further. ML is maybe a secondary target but they can't really get first-class support without solving all those other problems. So, they've built what they can on ROCm and if it doesn't run on your hardware welp, not doing that, sucks to be you. They really really need some PTX equivalent (or just outright PTX support ala GPU Ocelot) for any sort of serious adoption. PTX gives NVIDIA an incredible forwards-and-backwards support story and AMD just is like "lol compile it for each individual chip in each individual family". No way.