9 ms·

> AMD diverged their GPU architecture development into separate CDNA and RDNA lines specialized for compute and graphics respectively. Ooooh, is that why the c

• CuriousCosmic 3y ago
  They added support for high end radeon cards 2 months ago. Rocm is "eventually" coming to RDNA in general but it's a slow process which is more or less in line with how AMD has approached rocm from the start (targetting a very small subset of compute and slowly expanding it with each major version). https://www.tomshardware.com/news/amd-enables-rocm-and-pytorch-on-radeon-rx-7900-xtx https://www.tomshardware.com/news/amd-enables-rocm-and-pytor...
  • mnau 3y ago
    That's a good step forward. This separation is a massive barrier to entry. Making CUDA work reliably on every product was a masterstroke by NVIDIA.
    • deskamess 3y ago
      I am getting the impression their (AMD) understanding of software/Devx is not as good as nvidia. There seems to be some sort of inertia in getting the software side moving - as if, now that they are behind, they are not willing to make any mistakes, so they hold off on doing anything decisive - instead opting for continuing the status quo mode but perhaps adding a few more resources.
  • treprinum 3y ago
    The issue is that RDNA and CDNA are different so when an enthusiast makes a fast RDNA code it doesn't mean it would work well on CDNA and vice-versa. Not sure why AMD had to go this route, only high-end pros will write software for CDNA and they won't get any mindshare.
    • JonChesterfield 3y ago
      What do you have in mind for code that works noticeably better on one than the other?
    • CuriousCosmic 3y ago
      That's not accurate at all. Someone writing for the rocm platform will be writing HIP and then HIPCC will compile that down into the actual runtime targeting the given architecture. HIP is pretty platform agnostic so very little device specific optimization tends to go into idiomatic HIP.
      • treprinum 3y ago
        There are many low-level details in CUDA to get it working fast on a given GPU architecture that compilers don't address at all.
• DarkmSparks 3y ago
  I was quite surprised to find at least one of the the top500 is based on AMD gpus, it seems to me not bringing that to the consumer market was a conscious choice made some time ago.
  • fomine3 3y ago
    Some HPC applications are specially made for the HPC, so minor API is acceptable for some HPCs. That's not the case for consumer GPGPU use case.
  • slavik81 3y ago
    There are eleven CDNA 2 systems in the top500. https://www.top500.org/lists/top500/list/2023/11/?page=1 https://www.top500.org/lists/top500/list/2023/11/?page=1
    • DarkmSparks 3y ago
      thank you, I hadn't looked at the exact break down, just ran in to one of them a few weeks ago. I found it surprising because I wasn't aware at the time there was any, and it's not like it isn't something I should have known.
  • nolok 3y ago
    They're far behind Nvidia in gaming, to they try to compete on price to get market share back. Eg the 7900 XTX competes with the 4090 in rastering but is between 30 and 50% cheaper, 7900 XT / 4080, 7800 XT / 4070 are all winning by decent amount in pricing. Frankly this focus has allowed them to catch back in a field they've behind for more than a decade now. The rise of RT and other compute tools in gaming (DLSS and co) is hurting this strategy, but their APU being on PS5 AND Xbox Series keep them in the race, game engines and game developpers need to make it work on AMD tech. With Nvidia pricing and memory choice this generation, it's the first time in a while that bying an AMD card for gaming is the better choice at almost every price point (unless you can afford the 4090).
• cogman10 3y ago
  Looks like the split was around 2016? Which could make sense given the state of crypto at the time. One problem that hit nvidia more than AMD is consumer cards getting vacuumed up by crypto farms. AMD making a conscious split effectively isolated their compute cards from their gamer cards. That being said, I can't imagine this is something that's been good for adoption of AMD cards for compute tasks. The wonderful thing about CUDA is you don't need a special accelerator card to develop cuda code.
  • Zardoz84 3y ago
    if i remember correctly, AMD GPU cards was being sold very well to crypto miners. The split wasn't because that. They did, because gamming and computing having different hardware optimization requisites, and that allowed to get better and more competitive GPUs and computing cards on the market.
  • wmf 3y ago
    You can't really isolate crypto mining. If a gaming card is profitable to mine with, miners will buy it and use the gaming drivers.
    • segfaultbuserr 3y ago
      Correct. Whether or not a card has official GPGPU support is irrelevant for its use in mining, you can use pure Direct3D or OpenGL for mining if you really want it. The decision to not support customer GPGPU by AMD only hampers other useful non-mining applications. Ironically, mining is probably the most optimized GPGPU application a regular end-user can run on AMD GPUs. One reason was that GCN was a computing-first GPU, but also that miners have a strong motivation to go through the troubles of overcoming the lack of computing support by AMD. They would write the entire application in OpenCL 1.0 and optimize it to extract the last bit of performance in spite of its difficulties - the hashing kernels used for mining also tends to be much simpler than other applications, so it's feasible to do so. Meanwhile other people who want a decent programming environment would've picked CUDA without looking back.
  • dotnet00 3y ago
• ColonelPhantom 3y ago
  > Ooooh, is that why the consumer cards don't do compute? No, not really. Sure, the consumer cards are based on a less suitable architecture, so they won't be as good, but it's not like it's not a general purpose GPU architecture anymore. The real problem is that ROCm has made the very weird technical decision of shipping GPU machine code, rather than bytecode. Nvidia has their own bytecode NVPTX, and Intel just uses SPIR-V for oneAPI. This means that ROCm support for a GPU architecture requires shipping binaries of all the libraries (such as rocBLAS, rocDNN, rocsparse, rocFFT) for all architectures. As the cherry on top, on paper one GPU family consists of different architectures! The RX 6700 XT identifies as a different 'architecture' (gfx1031) than the RX 6800 XT (gfx1030). These are 'close enough' that you can tell ROCm to use gfx1030 binaries on gfx1031 and it'll usually just work, but still. I feel like this is a large part of the reason AMD is so bad about supporting older GPUs in ROCm. It'd cost a bit of effort, sure, but I feel like the enormous packages you'd get are a bigger issue. (This is another factor that kills hobbyist ROCm, because anyone with a Pascal+ GPU can do CUDA, but ROCm support is usually limited to newer and higher end cards.)
  • slavik81 3y ago
    > As the cherry on top, on paper one GPU family consists of different architectures! The RX 6700 XT identifies as a different 'architecture' (gfx1031) than the RX 6800 XT (gfx1030). These are 'close enough' that you can tell ROCm to use gfx1030 binaries on gfx1031 and it'll usually just work, but still. As far as I can tell, the gfx1030 and gfx1031 ISAs are identical in all but name. LLVM treats them exactly the same and all tests for the ROCm math libraries will pass when you run gfx1030 code on gfx1031 GPUs using the override. The Debian package for HIP has a patch so that if the user has a gfx1031 GPU and there are no gfx1031 code objects available, it will fall back to using gfx1030 code objects instead. When I proposed that patch upstream, it was rejected in favour of adding a new ISA that explicitly supports all the GPUs in a family. That solution is more complex and is taking longer to implement, but will more thoroughly solve that problem (as the solution Debian is using only works well when there's one ISA in the family that is a subset of all the others).
  • JonChesterfield 3y ago
    There was a ship-bytecode idea branded HSAIL, associated with opencl finalisers in some way. I'm not sure what killed that - would speculate that the compiler backend was annoyingly slow to run as a JIT. It's somewhat conceptually popular under the spirv branding now. Some of the ROCm libraries are partially written in assembly. Hopefully they all have C reference implementations that can be compiled for the other architectures. My guess is that the AMD strategy of only shipping libraries for some cards + open source means ROCm-ish as built by Linux distros, who are likely to build the libs for all the architectures and not just the special few, can be expected to drive people away from the official releases.
• beebeepka 3y ago
  I thought trolling wasn't welcome on HN
• vegabook 3y ago
  AMD has always been a terrible steward of ATI. They're fundamentally a hardware company (as per Lisa Su's CV) which didn't cotton on to the fact that Cuda was the killer. I remember how @Bridgman kept playing a rearguard action on Phoronix, his job being to keep devs on board. Losing battle. I kinda understand it because [80/90]s era hardware people intrinsically think hardware is the top dog in the stack, and that's where all AMD management come from including Su. Kodura understood that Nvidia was killing AMD because the consumer cards could run CUDA. So he pushed through, against Lisa Su, the Radeon VII, which until very recently, and for many years, was the only consumer card that ROCm supported. He was basically fired shortly thereafter, and the RVII, which was a fantastic card, was shutdown sharpish. Then they brought in Wang who crystallised the consumer/pro segmentation. Now they're furiously trying to backpedal, and it's too late. There are multiple attempting competitors, but basically the only one worth talking about is AAPL and Metal. AMD lost the window.
  • simfree 3y ago
    ATI on its own did not have a solid future, they could have easily ended up like their other local Canadian counterparts Nortel or Blackberry.
    • vegabook 3y ago
      "Dead or Canadian" yes?
    • hylaride 3y ago
      I live in Toronto and knew people who worked for ATI back in the 1990s-2000s. The management structure was fucked. In those days it was generally regarded that ATI could and did produce better hardware than NVIDIA, but ATI’s drivers were horrible and only evened out near the end of the hardware’s lifetime. But the end of the lifetime was far too late and all the benchmarks would have long been done on the buggy drivers, driving people to NVIDIA. I kid you not, but the software side of ATI’s reviews and incentives were literally QA got rewarded for finding bugs and then the software engineers were then rewarded for fixing them. You can imagine what happened next. The bitch of it is that it was overall just a symptom of the problem that the company as a whole didn’t prioritize software. NVIDIA knew that the drivers and software efficiency of using the hardware was just as if not more important than the hardware (the stories in the 1990s of how John Carmack used various hacks with hardware is a good example of that).
• sva_ 3y ago
  Well the APU does, there are compute intrinsics and even a small guide by AMD on how to use them: https://gpuopen.com/learn/wmma_on_rdna3/ https://gpuopen.com/learn/wmma_on_rdna3/
  • pauljurczak 3y ago
    How do you use these intrinsics on an APU? https://llvm.org/docs/AMDGPUUsage.html https://llvm.org/docs/AMDGPUUsage.html ?
• Const-me 3y ago
  > the consumer cards don't do compute? Typically, software developers only support a single GPGPU API, and that API is nVidia CUDA. Technically, consumer AMD cards are awesome at compute. For example, UE5 renders triangle meshes with compute instead of graphics https://www.youtube.com/watch?v=TMorJX3Nj6U https://www.youtube.com/watch?v=TMorJX3Nj6U Moreover, AMD cards often outperform nVidia equivalents because nVidia prioritized ray tracing and DLSS over compute power and memory bandwidth. The issue is, no tech company is interested in adding D3D or Vulkan backend to AI libraries like PyTorch. nVidia is not doing that because they are happy with the status quo. Intel and AMD are not doing that because both hope to replace CUDA with their proprietary equivalents, instead of an open GPU API.
  • boppo1 3y ago
    >Vulkan backend to AI libraries like PyTorch How many man hours is a project like this?
    • Const-me 3y ago
      Couple times in the past I wanted to port open source ML models from CUDA/Python to a better technology stack. I have ported Whisper https://github.com/Const-me/Whisper/ https://github.com/Const-me/Whisper/ and Mistral https://github.com/Const-me/Cgml/ https://github.com/Const-me/Cgml/ to D3D11. I don’t remember how much time I spent, but given both were unpaid part-time hobby projects, probably under 160 hours / each. These software projects were great to validate the technology choices, but note I only did bare minimum to implement specific ML models. Implementing a complete PyTorch backend gonna involve dramatically more work. I can’t even estimate how much more because I’m not an expert in Python or these Python-based ML libraries.
      • versteegen 3y ago
        Wow, a very nice reimplementation. To go on a tangent, I note your custom 'BCML1' 5bit per weight compression codec and your optimised hand-coded AVX2 to encode it... was that really needed? Are the weights encoded on every startup? Why not do it once and save to disk?
• 7speter 3y ago
  The big kicker is that cdna is still based on the much maligned
• Pomfers 3y ago
  AMD consumer cards do compute, but do not have a developed or well supported ecosystem (ROCm is a mess). Misguided segmentation or a high level architecture problem however, it is not. A specialized product will perform its specialty better than a general purpose product. There's minimal demand for a card that's good at both compute and gaming. These people exist, but are few compared to those who only care about one or the other. The benefit of splitting GCN into RDNA and CDNA was immediate. Comparing the Radeon VII (GCN 5) vs RX 5700 XT (RDNA 1), you'll see that they're fairly evenly matched on gaming, trading blows with the Radeon VII slightly ahead when averaged. The RX 5700 XT takes a very heavy loss on compute benchmarks. Both are TSMC 7nm, but the RX 5700 XT has fewer shaders (2560 vs 3840), a smaller die (251 vs 311 mm2), and lower power consumption (225 vs 300 w) which shows how much more efficient it is at gaming. That much lower power consumption and noise, and a couple hundred dollars cheaper made it a much more compelling card for gamers. CDNA cards are apparently missing components needed for gaming, like render output units. Hence, they have no official support for DirectX, OpenGL, or Vulkan. I've never seen anyone get one of these working for gaming. In exchange, their compute performance is so good that a number of companies are buying these cards over Nvidia's, despite the overwhelming CUDA ecosystem. In 2013, a GCN based supercomputer made the top 100. That is the one and only GCN based system to ever make the top 100. Compare to now, where 8 of the top 10 most energy efficient super computers use CDNA accelerators, as does the number 1 fastest supercomputer outright.
  • diego_sandoval 3y ago
    > These people exist, but are few compared to those who only care about one or the other. They're few, but they're very important, because 5 years from now, they will be the ones working for the companies that AMD will want to sell their compute cards to. The reasons you cite may still be more important. I'm not saying AMD made a bad decision. I'm just saying that neglecting the path from hobbyist to professional (or student to professional) is not insignificant.
    • Dylan16807 3y ago
      Consumer cards that are okay at compute do that job almost as well. And RDNA meets that bar... when the software works.