8 ms·

This confirms what everyone who ever touched AMD GPGPUs knows -- that the only thing holding back AMD from becoming a 2 Trillion dollar company is their absolut

by zero_k 3y ago

This confirms what everyone who ever touched AMD GPGPUs knows -- that the only thing holding back AMD from becoming a 2 Trillion dollar company is their absolutely atrocious software. I remember finding a bug in their OpenCL compiler [1], but crashing their OpenCL compiler via segfault was also a piece of cake (that was never fixed, I gave up on reporting it). AMD not developing a competitor to CUDA was the most short-sighted thing I have ever seen. I have no idea why their board hasn't been sacked and replaced with people who understand that you can make the best hardware out there, but if your SW to use it is -- to be very mild -- atrocious, nobody is gonna buy it or use it. Us, customers, are left to buy the overpriced NVidia cards because AMD's board is too rich to give a damn about a trillion or so of value left on the table. Just... weird. Whoever owns AMD stock I hope is asking questions, because that board needs to go down the nearest drain. [1] https://github.com/msoos/amdmiscompile https://github.com/msoos/amdmiscompile -- they eventually fixed this

outworlder 3y ago
> This confirms what everyone who ever touched AMD GPGPUs knows -- that the only thing holding back AMD from becoming a 2 Trillion dollar company is their absolutely atrocious software. Indeed. On the flip side they are quite more friendly to open-source, in general, compared to NVidia that's actively hostile(and has been for a while(see Linus "F* you!" video). Companies that develop hardware generally suck at software. There are exceptions, but they aren't numerous (and indeed have been rewarded in their stock price). I do not know anything about AMD's company culture in their software business units, but fixing that generally requires pretty large changes. > I have no idea why their board hasn't been sacked and replaced with people who understand that you can make the best hardware out there, but if your SW to use it is -- to be very mild -- atrocious, nobody is gonna buy it or use it. You probably can't just replace the board (unless C-level mandates are the only thing dragging down the company). You need to replace many more management levels, including a sizable portion of middle management. Sometimes even ICs if software hiring hasn't been properly handled.
- littlestymaar 3y ago
  > Companies that develop hardware generally suck at software. There are exceptions, but they aren't numerous (and indeed have been rewarded in their stock price) True, and you can even get the highest market cap as a hardware manufacturer who suck at software.
- paulmd 3y ago
  > Indeed. On the flip side they are quite more friendly to open-source, in general, those are "community-friendly" segfaults I guess, and it's really only a demonstration of how user-hostile NVIDIA is, what with their working HDMI 2.1 support and compilers and runtimes that actually build and run properly... /s the "open-source so good!" stuff only really only matters when the open-source stack at least gets you across the starting line. When you are having to debug AMD's openCL runtime or compiler and submit patches because it segfaults on the demo code, that is not "engaging the community as a force-multiplier", it's shipping a defective product and fobbing it off on the community to do your job for you. It's incumbent on AMD to at least get the platform to the starting line, and their failure to do that has been a problem for over a decade at this point. Also, honestly, even if you submit a patch how long until they break something else? If demo projects don’t even run… they aren’t exactly doing their technical diligence. People seem to love love love the idea of being an ongoing, unpaid employee working on AMD’s tech stack for them, and nvidia is just sitting there with a working product that people don’t like for ideological reasons… To wit: the segfault/deadlock issues geohot ran into aren’t just a one-off, they’re a whole class of bug that AMD has been fighting for years in ROCm, and they keep coming back. Are you willing to keep fixing that bug every couple months for the rest of your projects life? After they drop support for your hardware in 6 months, are you willing to debug the next AMD platform for them too?
wruza 3y ago
Can someone explain like I'm javascript, what's the deal with GPGPU? My naive understanding is that a graphics card is just a funny computer on which you can upload opcodes and data and let it cook itself. Why is CUDA such a big deal? Can't AMD just give direct access to its GPU as if it was an array of 4096 Arduino boards?
- dist-epoch 3y ago
  CUDA is like the TypeScript compiler which takes your nice code and turns it into something the browser (NVIDIA GPU) can run. AMD only has CoffeScript and it sucks compared to the TypeScript from NVIDIA.
- UncleEntity 3y ago
  [flagged]
  - deleted 3y ago
    [deleted]
- dotnet00 3y ago
  The kind of GPGPU code where the language is a thin architecture agnostic layer over the opcodes is how most GPU code (eg shaders used in graphics applications) are implemented. This is also how OpenCL, Vulkan Compute etc do their thing. This approach requires a lot of boilerplate and babysitting, but works well for relatively short bits of code. CUDA is much higher level. It's roughly on par with a "C++ is C with classes" level in terms of language capability. This makes it much easier to develop complex applications. The C compatibility means that you can reuse the exact same code between CPU and GPU in many cases. It eliminates a lot of boilerplate, since you don't need to manage your data in as much detail (eg, while you still have to make sure your pointers are valid for the GPU, the code for uploading the function arguments is generated by the CUDA compiler). The value add that makes CUDA especially strong is all the first party libraries which have been carefully optimized and have widespread and proven long term support.
  - 3y ago
KronisLV 3y ago
> This confirms what everyone who ever touched AMD GPGPUs knows -- that the only thing holding back AMD from becoming a 2 Trillion dollar company is their absolutely atrocious software. I actually rather enjoyed the AMD Software in particular, since it made very easy to tweak graphics (limit framerates to 60 when I don't want the GPU maxing out when games/software don't support it by default), setup instant replays with a hotkey press (like Shadowplay, where it has a constant recording buffer of the last X minutes) and also both power limit the GPU (when my UPS wasn't very good) as well as overclock it automatically (since I still want to squeeze like a year out of my RX 580). Except that any version of the software/drivers after around 2020 crashes VR titles after less than an hour. And that there is no software package for Linux and CoreCtrl isn't as good. And that sometimes the instant replay thing just doesn't work. And that I haven't been able to get ROCm working with any of the local LLMs even once across both Windows and Linux (DKMS sure loved to do a whole bunch of pointless compiling upon each apt upgrade). I'm honestly considering either going for Intel Arc as my next GPU because I'm curious, or just going back to something from Nvidia, so it's probably a split between: A580, RX 6600, RTX 3050. Or maybe I can hold out until other parts drop in price, time will tell.
sorenjan 3y ago
I don't understand why AMD doesn't cooperate with Intel to push SYCL as the standard GPGPU and heterogeneous programming method. Intel is good with software, SYCL is an open standard so both companies would benefit from the same code, and customers could run SYCL code on Threadrippers if they wanted (some of them are as fast as some GPUs now). Is AMD trying to create their own proprietary lock in eco system? Why aren't they committing to cross platform open standards?

by zero_k 3y ago

outworlder 3y ago

> This confirms what everyone who ever touched AMD GPGPUs knows -- that the only thing holding back AMD from becoming a 2 Trillion dollar company is their absolutely atrocious software. Indeed. On the flip side they are quite more friendly to open-source, in general, compared to NVidia that's actively hostile(and has been for a while(see Linus "F* you!" video). Companies that develop hardware generally suck at software. There are exceptions, but they aren't numerous (and indeed have been rewarded in their stock price). I do not know anything about AMD's company culture in their software business units, but fixing that generally requires pretty large changes. > I have no idea why their board hasn't been sacked and replaced with people who understand that you can make the best hardware out there, but if your SW to use it is -- to be very mild -- atrocious, nobody is gonna buy it or use it. You probably can't just replace the board (unless C-level mandates are the only thing dragging down the company). You need to replace many more management levels, including a sizable portion of middle management. Sometimes even ICs if software hiring hasn't been properly handled.

littlestymaar 3y ago
> Companies that develop hardware generally suck at software. There are exceptions, but they aren't numerous (and indeed have been rewarded in their stock price) True, and you can even get the highest market cap as a hardware manufacturer who suck at software.
paulmd 3y ago
> Indeed. On the flip side they are quite more friendly to open-source, in general, those are "community-friendly" segfaults I guess, and it's really only a demonstration of how user-hostile NVIDIA is, what with their working HDMI 2.1 support and compilers and runtimes that actually build and run properly... /s the "open-source so good!" stuff only really only matters when the open-source stack at least gets you across the starting line. When you are having to debug AMD's openCL runtime or compiler and submit patches because it segfaults on the demo code, that is not "engaging the community as a force-multiplier", it's shipping a defective product and fobbing it off on the community to do your job for you. It's incumbent on AMD to at least get the platform to the starting line, and their failure to do that has been a problem for over a decade at this point. Also, honestly, even if you submit a patch how long until they break something else? If demo projects don’t even run… they aren’t exactly doing their technical diligence. People seem to love love love the idea of being an ongoing, unpaid employee working on AMD’s tech stack for them, and nvidia is just sitting there with a working product that people don’t like for ideological reasons… To wit: the segfault/deadlock issues geohot ran into aren’t just a one-off, they’re a whole class of bug that AMD has been fighting for years in ROCm, and they keep coming back. Are you willing to keep fixing that bug every couple months for the rest of your projects life? After they drop support for your hardware in 6 months, are you willing to debug the next AMD platform for them too?

wruza 3y ago

Can someone explain like I'm javascript, what's the deal with GPGPU? My naive understanding is that a graphics card is just a funny computer on which you can upload opcodes and data and let it cook itself. Why is CUDA such a big deal? Can't AMD just give direct access to its GPU as if it was an array of 4096 Arduino boards?

dist-epoch 3y ago
CUDA is like the TypeScript compiler which takes your nice code and turns it into something the browser (NVIDIA GPU) can run. AMD only has CoffeScript and it sucks compared to the TypeScript from NVIDIA.
UncleEntity 3y ago
[flagged]
- deleted 3y ago
  [deleted]
dotnet00 3y ago
The kind of GPGPU code where the language is a thin architecture agnostic layer over the opcodes is how most GPU code (eg shaders used in graphics applications) are implemented. This is also how OpenCL, Vulkan Compute etc do their thing. This approach requires a lot of boilerplate and babysitting, but works well for relatively short bits of code. CUDA is much higher level. It's roughly on par with a "C++ is C with classes" level in terms of language capability. This makes it much easier to develop complex applications. The C compatibility means that you can reuse the exact same code between CPU and GPU in many cases. It eliminates a lot of boilerplate, since you don't need to manage your data in as much detail (eg, while you still have to make sure your pointers are valid for the GPU, the code for uploading the function arguments is generated by the CUDA compiler). The value add that makes CUDA especially strong is all the first party libraries which have been carefully optimized and have widespread and proven long term support.
- 3y ago

KronisLV 3y ago

> This confirms what everyone who ever touched AMD GPGPUs knows -- that the only thing holding back AMD from becoming a 2 Trillion dollar company is their absolutely atrocious software. I actually rather enjoyed the AMD Software in particular, since it made very easy to tweak graphics (limit framerates to 60 when I don't want the GPU maxing out when games/software don't support it by default), setup instant replays with a hotkey press (like Shadowplay, where it has a constant recording buffer of the last X minutes) and also both power limit the GPU (when my UPS wasn't very good) as well as overclock it automatically (since I still want to squeeze like a year out of my RX 580). Except that any version of the software/drivers after around 2020 crashes VR titles after less than an hour. And that there is no software package for Linux and CoreCtrl isn't as good. And that sometimes the instant replay thing just doesn't work. And that I haven't been able to get ROCm working with any of the local LLMs even once across both Windows and Linux (DKMS sure loved to do a whole bunch of pointless compiling upon each apt upgrade). I'm honestly considering either going for Intel Arc as my next GPU because I'm curious, or just going back to something from Nvidia, so it's probably a split between: A580, RX 6600, RTX 3050. Or maybe I can hold out until other parts drop in price, time will tell.

sorenjan 3y ago

I don't understand why AMD doesn't cooperate with Intel to push SYCL as the standard GPGPU and heterogeneous programming method. Intel is good with software, SYCL is an open standard so both companies would benefit from the same code, and customers could run SYCL code on Threadrippers if they wanted (some of them are as fast as some GPUs now). Is AMD trying to create their own proprietary lock in eco system? Why aren't they committing to cross platform open standards?