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

111–120 of 147 posts

Re: PyTorch 1.8, with AMD ROCm support

#111

Post by sillysaurusx »

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…

and TPUs

BS. There's so much effort getting Pytorch working on TPUs, and at the end of it it's incredibly slow compared to what you have in Tensorflow. I hate this myth and wish it would die.

Old thread on this, detailing exactly why this is true: https://news.ycombinator.com/item?id=24721229

Re: PyTorch 1.8, with AMD ROCm support

#112

Post by jpsamaroo »

krastanov wrote: post #5
porphyra wrote: post #4

Earlier quoted context omitted.

Lack of ROCm support in consumer RDNA 2 GPUs really makes it impossible for regular people to use ROCm. As an owner of an AMD Radeon RX 6800 I'm pretty salty about it.

I am getting some conflicting messages about support. There is a small group of people working on ROCm for Julia (in AMDGPU.jl) and while that work is still alpha quality, they seem to expect even devices as old as RX 580 to work. Are all of these support issues something that is on the ROCm/AMD/driver side, or are they on the side of libraries like pytorch?

This is an issue with AMD not wanting to long-term support the code paths in ROCm components necessary to enable ROCm on these devices. My hope is that Polaris GPU owners will step up to the plate and contribute patches to ROCm components to ensure that their cards keep working, when AMD is unwilling to do the leg work themselves (which is fair, they aren't nearly as big or rich as NVidia).

Re: PyTorch 1.8, with AMD ROCm support

#113

Post by wing-_-nuts »

microtonal wrote: post #108
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 k…

Yeah I think having support for consumer level cards is really important because it makes it easier to have a pipeline of students who are familiar with your tech. These same folks advocate for AMD in the workplace and contribute to OSS on behalf of AMD. Forcing this to be a 'datacenter only' solution is really short sighted.

Re: PyTorch 1.8, with AMD ROCm support

#115

Post by qayxc »

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

Earlier quoted context omitted.

> 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).

That would imply that there even was a laptop market for AMD in the first place. As the market numbers show, up until last year, AMD simply wasn't relevant at all in the notebook segment, so what developer experience are you even talking about if there were no developers on AMD's platform?

Re: PyTorch 1.8, with AMD ROCm support

#116

Post by volta83 »

ipsum2 wrote: post #28
buildbot wrote: post #12

It also looks like they are in the progress of adding Apple metal support, possibly for the M1: Part of 1.8 is this issue: https://github.com/pytorch/pytorch/pull/47635

What's the point? If you have enough money to buy a brand new Apple M1 laptop, you can afford a training rig or cloud credits. Any modern discrete GPU will blow away any M1 laptop for training. Is anyone training ML models on their ultra-thin laptop?

> Any modern discrete GPU will blow away any M1 laptop for training.

Counter example: none of the AMD consumer GPUs can be used for training. So no, not any modern discrete GPU blows away the M1.

The M1 might not be a great GPGPU system, but it is much better than many systems with discrete GPUs.

Re: PyTorch 1.8, with AMD ROCm support

#117

Post by codethief »

my123 wrote: post #46
dheera wrote: post #41

Earlier quoted context omitted.

I'll also add a caveat that toolage for Jetson boards is extremely incomplete. They supply you with a bunch of sorely outdated models for TensorRT like Inceptionv3 and SSD-MobileNetv2 and VGG-16. WTF, it's 2021. If you want to use anything remotely state-of-the-art like EfficientDet or HRNet or Deeplab or whatever you're left in the dark. Yes you can run TensorFlow or PyTorch (thankfully they give you wheels for thos…

You have https://github.com/NVIDIA-AI-IOT/torch2trt as an option for example to use your own models on TensorRT just fine. And https://github.com/tensorflow/tensorrt for TF-TRT integration.

TF-TRT doesn't work nearly as well as pure TRT. On my Jetson Nano a 300x300 SSD-MobileNetV2 with 2 object classes runs at 5 FPS using TF, <10 FPS using TF-TRT and 30 FPS using TensorRT.

Re: PyTorch 1.8, with AMD ROCm support

#118

Post by dogma1138 »

vetinari wrote: post #95
kortex wrote: post #93

Earlier quoted context omitted.

We all started as noobs once. A sizeable market of GPGPU is academics who don't yet have their nix chops. Had to walk an undergrad through basic git branching the other day.

I understand, but look at from another POV: ROCm is an USP of the Linux platform. Windows has its own USPs (DirectX or Office, for example), MacOS the same (iOS development, for example). Why should Linux platform give up its competitive advantages against others? It would only diminish the reasons for running it. The other platforms won't do the same -- and nobody is bothered by that. In fact, it is generally consid…

ROCm isn’t a USP of the Linux platform it’s vendor locked.

It provides no competitive advantage to Linux, not to mention that that entire concept is a bitty laughable as far as FOSS/OS goes.

I don’t understand why AMD seems adamant at not wanting to be a player in the GPU compute market.

Close to Metal was aborted.

OpenCL was abandoned.

HSA never got off the ground.

ROCm made every technical decision possible to ensure it won’t be adopted.

Can’t get GPUs that could run it, can’t ship a product to customers because good luck buying the datacenter GPUs from AMD the MI100 is unavailable for purchase unless you make a special order and even then apparently AMD doesn’t want anyone to actually buy it, can’t really find GPU cloud instances that run it on any of the major providers.

So what exactly is it? It’s been 5 years and if you want today to develop anything on the platform you have to build a desktop computer, find overpriced hardware on the second hand market pay a premium for it, hope that AMD won’t deprecate it within months like they did with GCN 2/3 without even a heads up notice all so you can develop something that only you can run with no future compatibility or interoperability.

If this is the right tool for the job then the job is wrong.

Re: PyTorch 1.8, with AMD ROCm support

#119

Post by dogma1138 »

my123 wrote: post #32
AlphaSite wrote: post #25

Earlier quoted context omitted.

I think this is more of an issue that they have Compute optimised and Graphics optimised cards and Vega is their last compute optimised card. It would be very nice for them to refresh their compute cards as well.

They made new compute cards, but they aren’t available to customers. (Only businesses, under the Radeon Instinct brand) With the price to match for those...

They aren’t available for business either, you can buy a Tesla card in a microcenter or on Newegg, and through a million partners ranging from small system builders to Dell and HP.

Good luck getting an instinct card.

Re: PyTorch 1.8, with AMD ROCm support

#120

Post by codethief »

dheera wrote: post #41
my123 wrote: post #31

Earlier quoted context omitted.

Jetson Xavier NX, but that comes with a high price tag. It’s much more powerful however.

I'll also add a caveat that toolage for Jetson boards is extremely incomplete. They supply you with a bunch of sorely outdated models for TensorRT like Inceptionv3 and SSD-MobileNetv2 and VGG-16. WTF, it's 2021. If you want to use anything remotely state-of-the-art like EfficientDet or HRNet or Deeplab or whatever you're left in the dark. Yes you can run TensorFlow or PyTorch (thankfully they give you wheels for thos…

> I'll also add a caveat that toolage for Jetson boards is extremely incomplete.

A hundred times this. I was about to write another rant here but I already did that[0] a while ago, so I'll save my breath this time. :)

Another fun fact regarding toolage: Today I discovered that many USB cameras work poorly on Jetsons (at least when using OpenCV), probably due to different drivers and/or the fact that OpenCV doesn't support ARM64 as well as it does x86_64. :(

> They supply you with a bunch of sorely outdated models for TensorRT like Inceptionv3 and SSD-MobileNetv2 and VGG-16.

They supply you with such models? That's news to me. AFAIK converting something like SSD-MobileNetv2 from TensorFlow to TensorRT still requires substantial manual work and magic, as this code[1] attests to. There are countless (countless!) posts on the Nvidia forums by people complaining that they're not able to convert their models.

[0]: https://news.ycombinator.com/item?id=26004235

[1]: https://github.com/jkjung-avt/tensorrt_demos/blob/master/ssd... (In fact, this is the only piece of code I've found on the entire internet that managed to successfully convert my SSD-MobileNetV2.)

Post reply on HN