Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PyTorch 1.8, with AMD ROCm support

github.com

Post reply on HN
Print view View original

101–110 of 147 posts

Re: PyTorch 1.8, with AMD ROCm support

#101

Post by BadInformatics »

komuher wrote: post #79
jampekka wrote: post #69

Earlier quoted context omitted.

OTOH PyTorch seems to be highly explosive if you try to use it outside the mainstream use (i.e. neural networks). There's sadly no performant autodiff system for general purpose Python. Numba is fine for performance, but does not support autodiff. JAX aims to be sort of general purpose, but in practice it is quite explosive when doing something other than neural networks. A lot of this is probably due to supporting C…

Wait wat, jax and also pytorch is used in a lot more areas then NN's. Jax is even consider to do better in that department in terms on performance then all of julia so wat are u talking about

GP makes a fair point about JAX still requiring a limited subset of Python though (mostly control flow stuff). Also, there's really no in-library way to add new kernels. This doesn't matter for most ML people but is absolutely important in other domains. So Numba/Julia/Fortran are "better in that department in terms on performance" than JAX because the latter doesn't even support said functionality.

Re: PyTorch 1.8, with AMD ROCm support

#103

Post by 01100011 »

ebegnwgnen wrote: post #60
slavik81 wrote: post #26

Earlier quoted context omitted.

I work for AMD, but this comment contains exclusively my personal opinions and information that is publicly available. ROCm has not been abandoned. PyTorch is built on top of rocBLAS, rocFFT, and Tensile (among other libraries) which are all under active development. You can watch the commits roll in day-by-day on their public GitHub repositories. I can't speak about hardware support beyond what's written in the docs…

"Future plan"... it's been years and it's still "future plan". I want to buy AMD because they are more open than Nvidia. But Nvidia supports CUDA day one for all their graphic cards and AMD still don't have rocm support on most of their product even years after their release [0] Given AMD size & budget, the reason why they don't hire a few more employee full time on making rocm work with their own graphic card is bey…

> why they don't hire a few more employee

The reason is that it would take more than a few more employees to provide optimized support across all GPUs. If nothing else, it's a significant testing burden.

Re: PyTorch 1.8, with AMD ROCm support

#104

Post by _coveredInBees »

jampekka wrote: post #69
std_badalloc wrote: post #44

PyTorch is the most impressive piece of software engineering that I know of. So yeah, it's a nice interface for writing fast numerical code. And for zero effort you can change between running on CPUs, GPUs and TPUs. There's some compiler functionality in there for kernel fusing and more. Oh, and you can autodiff everything. There's just an incredible amount of complexity being hidden behind behind a very simple inter…

OTOH PyTorch seems to be highly explosive if you try to use it outside the mainstream use (i.e. neural networks). There's sadly no performant autodiff system for general purpose Python. Numba is fine for performance, but does not support autodiff. JAX aims to be sort of general purpose, but in practice it is quite explosive when doing something other than neural networks. A lot of this is probably due to supporting C…

I really don't understand the GPUs are overrated comment. As someone who uses Pytorch a lot and GPU compute almost every day, there is an order of magnitude difference in the speeds involved for most common CUDA / Open-CL accelerated computations.

Pytorch makes it pretty easy to get large GPU accelerated speed-ups with a lot of code we used to traditionally limit to Numpy. And this is for things that have nothing to do with neural-networks.

Re: PyTorch 1.8, with AMD ROCm support

#105

Post by daniel-thompson »

qayxc wrote: post #91
daniel-thompson wrote: post #73

Earlier quoted context omitted.

> AMD just doesn't seem to have the resources AMD's net income for 2020 was about $2.5B. If it was a management priority, they would fund more people to focus on this. I would love to support open-source drivers, but AMD's efforts with ROCm on consumer hardware are a joke. It's been said in other comments that AMD only cares about the datacenter. That certainly seems to be the case. So until AMD takes this seriously…

> So until AMD takes this seriously and gets a legitimate developer story together, I'm spending my money elsewhere. Fair enough. Thing is, AMD's market share in the mobile market has been below 15% over the past years [1] and only last year increased to about 20%. Of these 20%, how many notebooks are (think realistically for a second) intended to be used for DL while also not featuring an NVIDIA dGPU? ROCm on consum…

> ROCm on consumer cards isn't a priority for AMD, since profits are small compared to the datacentre market and there's not that many people actually using consumer hardware for this kind of work.

I think causality runs the other way: Profits are small and there aren't many people using AMD cards for this _because_ the developer experience for GPGPU on AMD is terrible (and that because it's not a priority for AMD).

Re: PyTorch 1.8, with AMD ROCm support

#106

Post by lgessler »

jampekka wrote: post #69
std_badalloc wrote: post #44

PyTorch is the most impressive piece of software engineering that I know of. So yeah, it's a nice interface for writing fast numerical code. And for zero effort you can change between running on CPUs, GPUs and TPUs. There's some compiler functionality in there for kernel fusing and more. Oh, and you can autodiff everything. There's just an incredible amount of complexity being hidden behind behind a very simple inter…

OTOH PyTorch seems to be highly explosive if you try to use it outside the mainstream use (i.e. neural networks). There's sadly no performant autodiff system for general purpose Python. Numba is fine for performance, but does not support autodiff. JAX aims to be sort of general purpose, but in practice it is quite explosive when doing something other than neural networks. A lot of this is probably due to supporting C…

I get what you mean by the GPUs are overrated comment, which is that they're thought of as essential in many cases when they're probably not, but in many domains like NLP, GPUs are a hard requirement for getting anything done

Re: PyTorch 1.8, with AMD ROCm support

#107

Post by microtonal »

rrss wrote: post #85
thecleaner wrote: post #63

Earlier quoted context omitted.

Its python wrappers on top of existing ThTensor library which was already provided by torch. But yes great engineering nonetheless.

I don't think this is a particularly accurate description of pytorch in 2021. Yeah, the original c++ backend came from torch, but I think most of that has been replaced. AFAIK, all the development of the c++ backend for pytorch over that last several years has been done as part of the pytorch project -it's not just python wrappers at this point.

What I like about PyTorch is that most of the functionality is actually available through the C++ API as well, which has 'beta API stability' as they call it. So, there are good bindings for some other languages as well. E.g., I have been using the Rust bindings in a larger project [1], and they have been awesome. A precursor to the project was implemented using Tensorflow, which was a world of pain.

Even things like mixed-precision training are fairly easy to do through the API.

[1] https://github.com/tensordot/syntaxdot

Re: PyTorch 1.8, with AMD ROCm support

#108

Post by microtonal »

wing-_-nuts wrote: post #97

So, for someone not familiar, how far is AMD behind Nvidia's CUDA? I ask because AMD clearly has better linux driver support than Nvidia, and it would be awesome if their AI/ML libs were catching up.

At my previous employer, we bought two Radeon VIIs (in addition to NVIDIA GPUs). The last time I tried it (just over ~6 months ago), there were still many bugs. Things would just crash and burn very frequently (odd shape errors, random crashes, etc.). Two colleagues reported some of those bugs in ROCm, but the bug reports were largely ignored.

Maybe out-of-the-box support for PyTorch will result in more polish. Who knows? Another issue is that AMD has not yet implemented support for consumer GPUs after Vega. You'd think that targeting researchers on a budget (most of academia) would help them improving the ecosystem and weed out bugs. But they only seem interested in targeting large data centers.

It's all a shame, because as you say, AMD graphics on Linux is awesome. And I think many Linux enthusiasts and researchers would be happy to use and improve ROCm to break NVIDIA's monopoly. Only if AMD actually cared.

Re: PyTorch 1.8, with AMD ROCm support

#109

Post by sorenjan »

vetinari wrote: post #86
sorenjan wrote: post #83

Earlier quoted context omitted.

> So ship linux version and let the customers decide whether they want it or not. What if I want to use GPGPU in Photoshop, or a game with more than two users? Or really anything aimed at consumers? > If you are doing server product That's irrelevant, server products can choose their own hardware and OS. > You can install Linux very easily "For a Linux user, you can already build such a system yourself quite triviall…

> What if I want to use GPGPU in Photoshop, or a game with more than two users? Or really anything aimed at consumers? Then use API supported on your target platform. It's not ROCm then. Maybe Vulcan Compute/DirectCompute/Metal Compute? > That's irrelevant, server products can choose their own hardware and OS. It is relevant for ROCm. > > You can install Linux very easily > "For a Linux user, you can already build su…

> Then use API supported on your target platform. It's not ROCm then.

That's the point, ROCm isn't suitable for things outside datacenters or maybe some workstations. Cuda is however, and that's what AMD should be aiming for. Their best bet is SYCL, but that uses ROCm as backend...

> Installing a suitable operating system - for a supposed hacker - is a convoluted, nonsensical action nowadays?

Again, if all you need is to run ROCm on your own computer Linux isn't a hurdle. If you want to ship software to customers you can't just say "switch OS", they're probably already using their computers for other things.

> Vega is not that old; the problem is that is not not procurable anymore, which, if you read my comment again, I agreed that it is a problem.

The fact that they used to support something isn't a relevant argument and I just don't see the point in bringing it up, other than to underline the fact that AMD doesn't care about compute support for the mass market anymore. At least we agree on one thing.

The splitting between graphics specific and compute specific hardware is an even bigger issue than Linux only. ROCm stands for RadeonOpenCompute, and their Radeon DNA hardware can't run it, so streamers can't use AMD hardware to play games and improve their mic sound, while it's trivial to do with Nvidias OptiX. And what good are all the ML models if you can't ship them to customers?

Re: PyTorch 1.8, with AMD ROCm support

#110

Post by jpsamaroo »

komuher wrote: post #79
jampekka wrote: post #69

Earlier quoted context omitted.

OTOH PyTorch seems to be highly explosive if you try to use it outside the mainstream use (i.e. neural networks). There's sadly no performant autodiff system for general purpose Python. Numba is fine for performance, but does not support autodiff. JAX aims to be sort of general purpose, but in practice it is quite explosive when doing something other than neural networks. A lot of this is probably due to supporting C…

Wait wat, jax and also pytorch is used in a lot more areas then NN's. Jax is even consider to do better in that department in terms on performance then all of julia so wat are u talking about

> Jax is even consider to do better in that department in terms on performance then all of julia so wat are u talking about

Please provide sources for this claim

Post reply on HN