7 ms·

AMD Publishes XDNA Linux Driver: Support for Ryzen AI on Linux

219 points by pella 3y ago

rjsw 3y ago
It would have been nice if it was dual licenced like their GPU drivers.
hnarayanan 3y ago
Unrelated to this, but related to RDNA3. I have a 7900 XT, and all my attempts at getting ROCm to work on different Linuxes seem to have failed at different points. Does anyone have a pointer to a clear explanation on how to get it to work?
- oynqr 3y ago
  Tried it last summer with an RX 7600 and it just worked by using the Arch packages in the repo.
- edg5000 3y ago
  I have read many reports of people giving up on it, claiming that it is terribly buggy and has been for a while. The question is, under what circumstances did AMD test it and what does AMD consider "working". Probably it works on some specific setups under certain use conditions.
  - redeeman 3y ago
    and thats the problem. Seriously, its not that hard, just make some goddamn software that you can build and use more or less anywhere, why is it that I can relatively easily build mesa with vulkan/opengl driver for AMD cards, but their "rocm" is an atrocious mess? Honestly, it just stinks of incompetence, or if one were otherwise inclined in beliefs, disgust for their customers. If AMD had been hiring japanese to make this, they would have had to close up shop as they would have all had to perform seppuku.
    - weebull 3y ago
      Rocm hasn't been the the problem in my experience. It's things like pytorch on rocm. It uses hippify to convert cuda code to hip rather than having native support. It "works", but it's an obvious second class citizen, and the developers don't seem to take bug reports / PRs seriously.
  - roenxi 3y ago
    More than likely they are testing it on specific server setups with a dedicated GPU handling compute workloads. Think supercomputers and maybe cloud provider setups. That'd make sense if someone in AMD ranked the opportunities by $ value and started working down the list fixing bugs. My anecdotal evidence with an AMD GPU is there are serious problems trying to use a graphics card to run graphics and throwing a few compute tasks at it - because X11 will reliably crash and the kernel graphics driver enters some sort of corrupt state. I think that is a use case that was beyond their design considerations to start with. There is a hint that servers are targeted because they supported linux first with ROCm, and had a very tight support matrix of what OS they expected people to use. Unfortunately, this strategy generates a lot of bad publicity and I'd guess has trouble gaining traction because people can't experiment cheaply with AMD hardware. They're progressing though and even with a dose of cynicism about their wherewithal there is a lot in the pipe that has the potential to take on CUDA. Even APUs are promising.
- kkielhofner 3y ago
  I've been working in this space for ~10 years at this point and have been attempting ROCm since the Vega days (pretty much since initial releases of ROCm ~six years ago). "Hello world" in torch? On a new install/card/config/even upgrade with a bit of fiddling I can get there (I have it more-or-less down at this point). Actually using something in a real world use case? Hours, days, or give up. Often the third scenario where I end up going back to CUDA because I just need to get something done. Messing around with different driver versions, docker containers, ROCm versions, obscure environment variables, weird random cherry picks/patches and hacks from spelunking a bunch of GH repos/discussions/PRs/blog posts/etc. Feels like it never ends. I talk about it quite a bit and I keep buying AMD hardware and putting time into this because I'm rooting for AMD. However, consider the CEO of Nvidia saying 30% of their cost/spend is on software. He gets it. I'm pretty convinced at this point that AMD just doesn't have software in their DNA, with even die-hard "Team Red" Windows gaming users frequently complaining about the quality of drivers. Drivers. For gaming. On Windows. Enter >80% Nvidia market share in that market and >90% market share in ML. They just don't get it and I'm pretty sure they never will. I expect Intel, Apple, and even new entrants in the field will be the ones to offer viable alternatives to the Nvidia/CUDA monopoly.
  - ahartmetz 3y ago
    For OpenGL and Vulkan drivers on Linux, AMD sort of fell into a good software culture by accident by hiring a bunch of good people that brought the Linux (kernel) / Xorg / Mesa culture with them. I am pretty happy with the results there! Not contradicting you about the other areas, although I do have some hope because things (well... mostly hardware) have already improved in the GPU department under Lisa Su.
    - kkielhofner 3y ago
      Su has been CEO of AMD for nearly 10 years. Does not contribute to my confidence. Of course with the AI goldrush they're paying a lot of lip-service to ROCm (pumping stock price?) but a couple of examples: 1) They just added official support to ROCm for the top-end consumer card they released over a year ago. Meanwhile in CUDA land Nvidia back-ported support to CUDA 11.8 well before Ada Lovelace/Hopper even launched. Worked with everything out there day of launch. Even newest CUDA 12 and their drivers support anything with Nvidia stamped on it from the past 6-7 years. Literally everything. 2) Just check their repos, Docker Hub, etc. It's embarrassing for them. They used Python 3.10 for ROCm 5.7 because its basically the bare-minimum/standard for any broader AI, ML, etc project. Oh neat, they released ROCm 6 to support their year old ~ $1000 card! Python 3.9? Ubuntu 20.04? What the hell? Pytorch "hello world" usable but almost nothing else even runs. The further you dig the more clownish it gets.
- ckastner 3y ago
  > I have a 7900 XT, and all my attempts at getting ROCm to work on different Linuxes seem to have failed at different points. Debian formed a ROCm Team a while ago and we are working hard on getting this to work out of the box, as in: apt-get install and you're done. For various reasons, our initial focus was on RDNA2 and CDNA2 and earlier, mainly because we are building a CI network in which we test all of our packages (and their reverse dependencies) on actual cards, and we had to bootstrap the network infrastructure first. CI is central to the Debian ecosystem but all our official infrastructure cannot deal with the requirements for specific hardware attached to a machine -- that was never a factor, until now. AMD has generously supported us with hardware donations, among which are RDNA3 cards. These are already in our possession, and it's just a question of person-time until these are integrated into our CI. We are already spec'ing the systems, though.
  - hackerlight 3y ago
    For a fresh Linux install with a 7900 XT/XTX, would Debian or Ubuntu be better (for Pytorch)?
    - hnarayanan 3y ago
      I would love the answer to this question. I’ve tried with Debian and Fedora and gotten to different stages of the journey, but not successfully in either case.
      - hackerlight 3y ago
        How long ago did you try? Before or after official AMD support? https://www.phoronix.com/news/Radeon-RX-7900-XT-ROCm-PyTorch https://www.phoronix.com/news/Radeon-RX-7900-XT-ROCm-PyTorch
        hnarayanan 3y ago
        After. I am still currently trying. (Apologies I missed your response earlier as this thread suddenly had a lot going on.)
- hackerlight 3y ago
  AMD has had official ROCm support for 7900 XT on Linux for ~2 months. How long ago did you try? https://www.phoronix.com/news/Radeon-RX-7900-XT-ROCm-PyTorch https://www.phoronix.com/news/Radeon-RX-7900-XT-ROCm-PyTorch
  - jsheard 3y ago
    Worth noting that the 7900 XT was released over a year ago, though. Having to wait half a hardware generation to actually use your hardware isn't ideal.
    - oynqr 3y ago
      It worked before that. Official just means that you can pay AMD for support.
  - hnarayanan 3y ago
    I have been trying different things for a few weeks now.
- klowner 3y ago
  I do know that I would love it if amdgpu would stop throwing null pointer dereference errors when I open Blender settings with my 7800XT.
- FoodWThrow 3y ago
  > pacman -S rocm-hip-sdk rocm-opencl-sdk I have the same card, the above works with everything I threw at it so far. Haven't even installed amdgpu-pro drivers btw, only have radv (that steam installed by default).
- CapsAdmin 3y ago
  You want to use rocm directly or with something like pytorch? If pytorch, keep in mind that most of the pytorch+rocm version is self contained, and you don't need to install every roc* package on your system for it to work. This confused me in the beginning at least.
  - hnarayanan 3y ago
    I would like to use PyTorch. If you got it working, could you please share some steps? I feel like I am losing my mind and the overall quality of the software and docs seem really poor.
- rwmj 3y ago
  I have a similar problem where it worked through Stable Diffusion / PyTorch (worked as in, didn't crash), but the resulting images are just full of garbage. I wish there was some sort of test tool or hello world that could be use to diagnose this stuff, but I didn't find anything. Edit: Example garbage image: http://oirase.annexia.org/tmp/stablediffusion/sunflower-2.png http://oirase.annexia.org/tmp/stablediffusion/sunflower-2.pn...
- JonChesterfield 3y ago
  The pieces all have exciting versions-must-roughly-match properties. The official distribution idea is pick exactly the recommended OS and install the binary package from amd and it'll be fairly solid. I totally ignore that recommendation and sometimes have a happily working system and sometimes it's a wreck. In particular, the upstream Linux driver (what you have anyway) and the dkms built one are sometimes rather divergent. Llvm in rocm has different behaviour to the upstream llvm too. I'm cautiously optimistic that Debian is packaging will end up as turn key just-works. Part of that is persuading AND developers that breaking ABI has consequences, which it kind of doesn't on the install all of rocm together model. Right now, I use Debian with the same kernel version that the ROCm recommended Ubuntu ships with and build the dkms driver source intended for Ubuntu on it. That be the wrong thing to do but also totally solid in ymmv fashion.
sylware 3y ago
Anybody can present the hardware programing interface? Is it memory mapped data buffer and circular command buffers?
neomantra 3y ago
Noting that AMD also operates OSS well in their NIC space. Onload and associated tools are on GitHub. Solarflare had the foresight long ago (>10 years) to be open source and that stewardship continued through acquisitions. [1] As an OSS contributor, that available software (via tarball from their website) allowed me to make public Docker tooling and other projects [2]. I would be less inclined to do so with proprietary binary bundles. But it wasn't "open collaboration" until recently -- but they were great on support emails! However, new GitHub projects are popping up from them even in the last few months! [3] And thus, I can independently and openly work on issues [4] and integrate their software with other tools [5], just yesterday. This all echoes to the recurrent Supabase thread of the value chain of OSS in companies[6]; there's a lot of reasons to do it. [1] https://web.archive.org/web/20180108154033/http://www.openonload.org/ https://web.archive.org/web/20180108154033/http://www.openon... [2] https://github.com/neomantra/docker-onload https://github.com/neomantra/docker-onload [3] https://github.com/Xilinx-CNS/sfptpd https://github.com/Xilinx-CNS/sfptpd [4] https://github.com/Xilinx-CNS/sfptpd/issues/6 https://github.com/Xilinx-CNS/sfptpd/issues/6 [5] https://github.com/neomantra/nomad-onload https://github.com/neomantra/nomad-onload [6] https://news.ycombinator.com/item?id=39087837 https://news.ycombinator.com/item?id=39087837
mattfrommars 3y ago
For folks who develop on Linux, do you have Linux as primary OS as in dual boot with windows? I'm thinking to begin developing on Linux but love to know what is the current strategy to develop on or for Linux. What I'm trying to say is of WSL2 and all the work Microsoft is doing with Linux operating system has any other bigger purpose beyond docker or container
- jchw 3y ago
  I am a very long-time user of desktop Linux as my only OS. I think the main challenge with using Linux as a desktop OS is just the desktop part of it. It's not grotesquely horrible, but if I wanted someone to think that it was, I'd know exactly what things to tell them to do to experience that. (It goes something like, buy an NVIDIA GeForce GTX 10xx series card and then try to run KDE Wayland on it.) I'm always good to braindump my thoughts so here goes. Hardware: If you want to run Linux as a primary desktop OS, please think about your hardware choices. There's a surprising amount of tradeoffs, and while the Linux desktop is generally a mess, I'd say this roughly defines people who wind up loving it versus hating it. Even in ways you could never realize, it will just impact your entire experience. - GPUs: If you go with AMD, you have to be aware that choosing the latest cards may not be the best choice. The software stack is rarely ever fully ready for a launch, and if you are not tracking the latest stable kernel it will take even longer to get kernel driver updates. That said, I strongly recommend AMD in general as AMD cards have been very reliable for me and have good drivers across the board once they're ready. NVIDIA has the advantage that you can pretty much get a card at launch and run it on Linux, one of the notable advantages of them staying out of mainline; on the other hand, if you want to keep up with the latest Linux kernels, you may find yourself unable to get the NVIDIA driver working sometimes, as it does not always work on mainline. Further, NVIDIA's drivers still have some issues on Wayland, although it's not nearly as bad as it used to be, though for compatibility reasons I would still not strongly recommend it. - NICs: Intel NICs generally work pretty good. They're not always perfect but they almost always have good mainline Linux support and reliability issues are definitely an exception case. WiFi is always a bit more persnickety, but things have gotten a lot better. The particular on-board WiFi used by my current motherboard is actually not generally recommended (A MEDIATEK MT7922), but I've been tracking mainline Linux and the only issues I've run into were unrelated. (There was an annoying issue with 6.6.5, it was fixed by 6.6.6 a few days later.) - Audio: Believe it or not, Linux audio has gotten very compelling lately, after decades of being probably the funniest joke about Linux. Be skeptical if you must, but Pipewire + Wireplumber is probably about as good as Linux audio has been, and has compelling pros and cons when compared even with commercial OSes. Bluetooth will probably work out of the box, and getting low latency "Pro" audio routing features without breaking your desktop audio no longer requires a bunch of specialized knowledge; nominally, it's a dropdown in your audio settings. That having been said... You may face some issues, especially with cutting-edge motherboards and laptops. In general, Linux does not adequately support laptops that need a lot of software DSP in the driver to sound good. In addition, some of the more advanced audio codec setups may not work correctly out of the box. This is NOT the case for the majority of desktop motherboards, but it is worth googling to see if you can find someone reporting that it works. Software: There is a lot of heated debates about what the best distro and desktop environments are. Normally, I'd recommend sticking with a stalwart like Debian, but in this changing environment I'm really not sure what I'd personally recommend. I run NixOS, which I think is a fantastic operating system for people who know they need it, but like Linux itself, I would not recommend it to anyone unless they're relatively sure it's something that solves a problem they actually have. I pretty much knew immediately I wanted it when I heard about it. But even when not considering NixOS, I strongly would recommend trying to find an "immutable" Linux distro that will work for you. This is because immutable Linux has proven to be a much better model for desktop usage that is far more robust and easier to reason about. A good example would be Fedora Silverblue. There was a nice looking project on here recently that may be of particular interest to developers, based on Silverblue, called Bluefin: https://projectbluefin.io/ https://projectbluefin.io/ I can't necessarily personally recommend it, but the concept seems solid. Recommending a random recent project is a little risky, but it at least has the benefit that it's essentially just a spin of Silverblue that can be reverted back to plain old Silverblue safely as far as I know. My personal choice for a desktop environment is none. I use SwayWM with a bunch of bespoke configuration. It's... ugly[1]. But it works, and for me, it works quite well. But that is a horrible recommendation for someone who is trying to get into Linux by any measure. Instead, I recommend KDE. KDE has a fair amount of stability issues, but what I can say about KDE is that it's got a great balance of customization, features and polish for a desktop system, and I think that the current iteration of KDE is going to age well into the future. We'll see how that thought holds up, but I have my hopes. If you are using an AMD card, I can also say that running KDE/Plasma Desktop in Wayland mode is a pretty good experience, if you can. It does come with some challenges and downsides, but there are some positives, especially if you like high DPI or high refresh rate screens, or you want to use OBS to capture or stream the screen, as it will be a lot more efficient using Pipewire on Wayland. At the very least, it's not a huge commitment since you can log out and jump back in with an X11 session through your display manager if anything goes too wrong. P.S.: While I don't immediately recommend anyone to go and try NixOS, I can't say the same about Nix. Go and install Nix on your macOS or Linux machines! It's a great tool to have and is generally not obtrusive on a machine. Especially see the `nix develop` command. It drops you in a shell with the development tools used to build a package, so I can do say, `nix develop nixpkgs#_86Box` to get all of the dependencies to build the 86Box emulator, and just start building it with CMake. [1]: https://github.com/jchv/nixos-config/tree/master/modules/programs/sway https://github.com/jchv/nixos-config/tree/master/modules/pro... - In case anyone is curious about a "real world" Sway setup, this certainly is one. In the back of my mind, I'm secretly hoping someone will suggest improvements. :)
JonChesterfield 3y ago
This is exciting. I don't know what it is but I am thrilled that more things associated with Xilinx are showing up in Linux. Can anyone add some context beyond the post as to what this is?
pella 3y ago
--> https://github.com/amd/xdna-driver https://github.com/amd/xdna-driver
- angm128 3y ago
  "To run AI applications (test machine): RyzenAI processor, example: Phoenix/Strix" Is there any strix besides the unreleased Strix Point and Strix Halo?
  - adrian_b 3y ago
    No. However the AMD CEO has confirmed recently that Strix Point (laptop Zen 5) will be released later this year (and it is currently being tested by AMD partners like Microsoft) and that it will include a NPU much faster than that of Hawk Point (Ryzen 8040 series) and Phoenix (Ryzen 7040 series). As Strix Point is currently in testing at external partners, they must have at least preliminary versions of the software for it.
shmerl 3y ago
Hopefully the plan is to upstream it.
im3w1l 3y ago
So what functionality does Ryzen AI have? I couldn't get past the marketing copy while trying to find it.
- p_l 3y ago
  It's a 4x4 configuration of the separately available Xilinx/AMD AIE-ML accelerator, available on Xilinx alveo platform IIRC. VLIW vector units optimized for AI (-ML suffix) with runtime reconfigurable network on a chip letting you optimize "streaming" the data between individual cores. The way "AMD IPU" device was implemented, which embeds the system in some new AMD CPUs, the previous drivers (which were Linux/RTOS only) didn't work. I was actually in the middle of reverse engineering how it was exposed in Phoenix (7940hs) APUs to write custom driver for Linux based on the one shipped for windows.
  - 3abiton 3y ago
    How does it compare to cuda in terms of versatility and compatibility? most AI frameworks are built around cuda (pytorch, etc..) which is why nvidia has a monopoly now, I fail to see AMD breaking through, but one can hope. Do you see a light at the end of the tunnel?
    - p_l 3y ago
      It's targeting the high power efficiency part of the spectrum where nvidia is much less available. There's some reasonably capable software support, in fact the linux driver linked is significantly more capable than the "SDK" they released so far for windows. Which makes sense, because under Xilinx brand they have been selling accelerators and SoCs using AIE and AIE-ML cores for various use cases in embedded world, and XRT lets you program those with pretty much plain C++. For some AI tasks, they have provided high-end wrappers for models that use ONNX (iirc) so those can be used immediately. This is not ROCm, and has essentially none of the ROCm bullshit in terms of support. I seem to recall there's some work to integrate parts of ROCm (opencl, HIP) with XRT. Definitely going to build some kernels with this and test drive it ASAP.
- 3y ago
sva_ 3y ago
Seems like RDNA3 is not supported.
- wmf 3y ago
  You use ROCm drivers for RDNA3 and XRT drivers for XDNA.
- shmerl 3y ago
  Isn't it an ASIC on the CPU? What does that have to do with RDNA3?
- p_l 3y ago
  It's a completely separate accelerator code, though there's possibility of maybe using it in combined fashion with HIP/ROCm OpenCL (I think there's OpenCL compiler for AIE and AIE-ML, but I'm not sure at how well it works yet)
  - sva_ 3y ago
    Ah, I wasn't really aware that there is a separate accelerator in the 7040 series, other than rdna3's wmma.
    - p_l 3y ago
      Yeah, it's Xilinx AIE, stuff that was already supported on Linux - but it was differently connected on 7040: the AIE module being connected direct to Infinity Fabric, masquerading as PCIE device, instead of existing PCIE driver which assumed mediation done by on-fpga CPU etc. At least that's how it looked from what I've read in XRT docs so far. This driver both provides necessary interface in place of an ARM core talking direct over AXI buses, and the glue logic to enable use of XRT.

219 points by pella 3y ago

rjsw 3y ago

It would have been nice if it was dual licenced like their GPU drivers.

Unrelated to this, but related to RDNA3. I have a 7900 XT, and all my attempts at getting ROCm to work on different Linuxes seem to have failed at different points. Does anyone have a pointer to a clear explanation on how to get it to work?

oynqr 3y ago
Tried it last summer with an RX 7600 and it just worked by using the Arch packages in the repo.
edg5000 3y ago
I have read many reports of people giving up on it, claiming that it is terribly buggy and has been for a while. The question is, under what circumstances did AMD test it and what does AMD consider "working". Probably it works on some specific setups under certain use conditions.
- redeeman 3y ago
  and thats the problem. Seriously, its not that hard, just make some goddamn software that you can build and use more or less anywhere, why is it that I can relatively easily build mesa with vulkan/opengl driver for AMD cards, but their "rocm" is an atrocious mess? Honestly, it just stinks of incompetence, or if one were otherwise inclined in beliefs, disgust for their customers. If AMD had been hiring japanese to make this, they would have had to close up shop as they would have all had to perform seppuku.
  - weebull 3y ago
    Rocm hasn't been the the problem in my experience. It's things like pytorch on rocm. It uses hippify to convert cuda code to hip rather than having native support. It "works", but it's an obvious second class citizen, and the developers don't seem to take bug reports / PRs seriously.
- roenxi 3y ago
  More than likely they are testing it on specific server setups with a dedicated GPU handling compute workloads. Think supercomputers and maybe cloud provider setups. That'd make sense if someone in AMD ranked the opportunities by $ value and started working down the list fixing bugs. My anecdotal evidence with an AMD GPU is there are serious problems trying to use a graphics card to run graphics and throwing a few compute tasks at it - because X11 will reliably crash and the kernel graphics driver enters some sort of corrupt state. I think that is a use case that was beyond their design considerations to start with. There is a hint that servers are targeted because they supported linux first with ROCm, and had a very tight support matrix of what OS they expected people to use. Unfortunately, this strategy generates a lot of bad publicity and I'd guess has trouble gaining traction because people can't experiment cheaply with AMD hardware. They're progressing though and even with a dose of cynicism about their wherewithal there is a lot in the pipe that has the potential to take on CUDA. Even APUs are promising.
kkielhofner 3y ago
I've been working in this space for ~10 years at this point and have been attempting ROCm since the Vega days (pretty much since initial releases of ROCm ~six years ago). "Hello world" in torch? On a new install/card/config/even upgrade with a bit of fiddling I can get there (I have it more-or-less down at this point). Actually using something in a real world use case? Hours, days, or give up. Often the third scenario where I end up going back to CUDA because I just need to get something done. Messing around with different driver versions, docker containers, ROCm versions, obscure environment variables, weird random cherry picks/patches and hacks from spelunking a bunch of GH repos/discussions/PRs/blog posts/etc. Feels like it never ends. I talk about it quite a bit and I keep buying AMD hardware and putting time into this because I'm rooting for AMD. However, consider the CEO of Nvidia saying 30% of their cost/spend is on software. He gets it. I'm pretty convinced at this point that AMD just doesn't have software in their DNA, with even die-hard "Team Red" Windows gaming users frequently complaining about the quality of drivers. Drivers. For gaming. On Windows. Enter >80% Nvidia market share in that market and >90% market share in ML. They just don't get it and I'm pretty sure they never will. I expect Intel, Apple, and even new entrants in the field will be the ones to offer viable alternatives to the Nvidia/CUDA monopoly.
- ahartmetz 3y ago
  For OpenGL and Vulkan drivers on Linux, AMD sort of fell into a good software culture by accident by hiring a bunch of good people that brought the Linux (kernel) / Xorg / Mesa culture with them. I am pretty happy with the results there! Not contradicting you about the other areas, although I do have some hope because things (well... mostly hardware) have already improved in the GPU department under Lisa Su.
  - kkielhofner 3y ago
    Su has been CEO of AMD for nearly 10 years. Does not contribute to my confidence. Of course with the AI goldrush they're paying a lot of lip-service to ROCm (pumping stock price?) but a couple of examples: 1) They just added official support to ROCm for the top-end consumer card they released over a year ago. Meanwhile in CUDA land Nvidia back-ported support to CUDA 11.8 well before Ada Lovelace/Hopper even launched. Worked with everything out there day of launch. Even newest CUDA 12 and their drivers support anything with Nvidia stamped on it from the past 6-7 years. Literally everything. 2) Just check their repos, Docker Hub, etc. It's embarrassing for them. They used Python 3.10 for ROCm 5.7 because its basically the bare-minimum/standard for any broader AI, ML, etc project. Oh neat, they released ROCm 6 to support their year old ~ $1000 card! Python 3.9? Ubuntu 20.04? What the hell? Pytorch "hello world" usable but almost nothing else even runs. The further you dig the more clownish it gets.
ckastner 3y ago
> I have a 7900 XT, and all my attempts at getting ROCm to work on different Linuxes seem to have failed at different points. Debian formed a ROCm Team a while ago and we are working hard on getting this to work out of the box, as in: apt-get install and you're done. For various reasons, our initial focus was on RDNA2 and CDNA2 and earlier, mainly because we are building a CI network in which we test all of our packages (and their reverse dependencies) on actual cards, and we had to bootstrap the network infrastructure first. CI is central to the Debian ecosystem but all our official infrastructure cannot deal with the requirements for specific hardware attached to a machine -- that was never a factor, until now. AMD has generously supported us with hardware donations, among which are RDNA3 cards. These are already in our possession, and it's just a question of person-time until these are integrated into our CI. We are already spec'ing the systems, though.
- hackerlight 3y ago
  For a fresh Linux install with a 7900 XT/XTX, would Debian or Ubuntu be better (for Pytorch)?
  - hnarayanan 3y ago
    I would love the answer to this question. I’ve tried with Debian and Fedora and gotten to different stages of the journey, but not successfully in either case.
    - hackerlight 3y ago
      How long ago did you try? Before or after official AMD support? https://www.phoronix.com/news/Radeon-RX-7900-XT-ROCm-PyTorch https://www.phoronix.com/news/Radeon-RX-7900-XT-ROCm-PyTorch
      - hnarayanan 3y ago
        After. I am still currently trying. (Apologies I missed your response earlier as this thread suddenly had a lot going on.)
hackerlight 3y ago
AMD has had official ROCm support for 7900 XT on Linux for ~2 months. How long ago did you try? https://www.phoronix.com/news/Radeon-RX-7900-XT-ROCm-PyTorch https://www.phoronix.com/news/Radeon-RX-7900-XT-ROCm-PyTorch
- jsheard 3y ago
  Worth noting that the 7900 XT was released over a year ago, though. Having to wait half a hardware generation to actually use your hardware isn't ideal.
  - oynqr 3y ago
    It worked before that. Official just means that you can pay AMD for support.
- hnarayanan 3y ago
  I have been trying different things for a few weeks now.
klowner 3y ago
I do know that I would love it if amdgpu would stop throwing null pointer dereference errors when I open Blender settings with my 7800XT.
FoodWThrow 3y ago
> pacman -S rocm-hip-sdk rocm-opencl-sdk I have the same card, the above works with everything I threw at it so far. Haven't even installed amdgpu-pro drivers btw, only have radv (that steam installed by default).
CapsAdmin 3y ago
You want to use rocm directly or with something like pytorch? If pytorch, keep in mind that most of the pytorch+rocm version is self contained, and you don't need to install every roc* package on your system for it to work. This confused me in the beginning at least.
- hnarayanan 3y ago
  I would like to use PyTorch. If you got it working, could you please share some steps? I feel like I am losing my mind and the overall quality of the software and docs seem really poor.
rwmj 3y ago
I have a similar problem where it worked through Stable Diffusion / PyTorch (worked as in, didn't crash), but the resulting images are just full of garbage. I wish there was some sort of test tool or hello world that could be use to diagnose this stuff, but I didn't find anything. Edit: Example garbage image: http://oirase.annexia.org/tmp/stablediffusion/sunflower-2.png http://oirase.annexia.org/tmp/stablediffusion/sunflower-2.pn...
JonChesterfield 3y ago
The pieces all have exciting versions-must-roughly-match properties. The official distribution idea is pick exactly the recommended OS and install the binary package from amd and it'll be fairly solid. I totally ignore that recommendation and sometimes have a happily working system and sometimes it's a wreck. In particular, the upstream Linux driver (what you have anyway) and the dkms built one are sometimes rather divergent. Llvm in rocm has different behaviour to the upstream llvm too. I'm cautiously optimistic that Debian is packaging will end up as turn key just-works. Part of that is persuading AND developers that breaking ABI has consequences, which it kind of doesn't on the install all of rocm together model. Right now, I use Debian with the same kernel version that the ROCm recommended Ubuntu ships with and build the dkms driver source intended for Ubuntu on it. That be the wrong thing to do but also totally solid in ymmv fashion.

sylware 3y ago

Anybody can present the hardware programing interface? Is it memory mapped data buffer and circular command buffers?

neomantra 3y ago

Noting that AMD also operates OSS well in their NIC space. Onload and associated tools are on GitHub. Solarflare had the foresight long ago (>10 years) to be open source and that stewardship continued through acquisitions. [1] As an OSS contributor, that available software (via tarball from their website) allowed me to make public Docker tooling and other projects [2]. I would be less inclined to do so with proprietary binary bundles. But it wasn't "open collaboration" until recently -- but they were great on support emails! However, new GitHub projects are popping up from them even in the last few months! [3] And thus, I can independently and openly work on issues [4] and integrate their software with other tools [5], just yesterday. This all echoes to the recurrent Supabase thread of the value chain of OSS in companies[6]; there's a lot of reasons to do it. [1] https://web.archive.org/web/20180108154033/http://www.openonload.org/ https://web.archive.org/web/20180108154033/http://www.openon... [2] https://github.com/neomantra/docker-onload https://github.com/neomantra/docker-onload [3] https://github.com/Xilinx-CNS/sfptpd https://github.com/Xilinx-CNS/sfptpd [4] https://github.com/Xilinx-CNS/sfptpd/issues/6 https://github.com/Xilinx-CNS/sfptpd/issues/6 [5] https://github.com/neomantra/nomad-onload https://github.com/neomantra/nomad-onload [6] https://news.ycombinator.com/item?id=39087837 https://news.ycombinator.com/item?id=39087837

mattfrommars 3y ago

For folks who develop on Linux, do you have Linux as primary OS as in dual boot with windows? I'm thinking to begin developing on Linux but love to know what is the current strategy to develop on or for Linux. What I'm trying to say is of WSL2 and all the work Microsoft is doing with Linux operating system has any other bigger purpose beyond docker or container

jchw 3y ago
I am a very long-time user of desktop Linux as my only OS. I think the main challenge with using Linux as a desktop OS is just the desktop part of it. It's not grotesquely horrible, but if I wanted someone to think that it was, I'd know exactly what things to tell them to do to experience that. (It goes something like, buy an NVIDIA GeForce GTX 10xx series card and then try to run KDE Wayland on it.) I'm always good to braindump my thoughts so here goes. Hardware: If you want to run Linux as a primary desktop OS, please think about your hardware choices. There's a surprising amount of tradeoffs, and while the Linux desktop is generally a mess, I'd say this roughly defines people who wind up loving it versus hating it. Even in ways you could never realize, it will just impact your entire experience. - GPUs: If you go with AMD, you have to be aware that choosing the latest cards may not be the best choice. The software stack is rarely ever fully ready for a launch, and if you are not tracking the latest stable kernel it will take even longer to get kernel driver updates. That said, I strongly recommend AMD in general as AMD cards have been very reliable for me and have good drivers across the board once they're ready. NVIDIA has the advantage that you can pretty much get a card at launch and run it on Linux, one of the notable advantages of them staying out of mainline; on the other hand, if you want to keep up with the latest Linux kernels, you may find yourself unable to get the NVIDIA driver working sometimes, as it does not always work on mainline. Further, NVIDIA's drivers still have some issues on Wayland, although it's not nearly as bad as it used to be, though for compatibility reasons I would still not strongly recommend it. - NICs: Intel NICs generally work pretty good. They're not always perfect but they almost always have good mainline Linux support and reliability issues are definitely an exception case. WiFi is always a bit more persnickety, but things have gotten a lot better. The particular on-board WiFi used by my current motherboard is actually not generally recommended (A MEDIATEK MT7922), but I've been tracking mainline Linux and the only issues I've run into were unrelated. (There was an annoying issue with 6.6.5, it was fixed by 6.6.6 a few days later.) - Audio: Believe it or not, Linux audio has gotten very compelling lately, after decades of being probably the funniest joke about Linux. Be skeptical if you must, but Pipewire + Wireplumber is probably about as good as Linux audio has been, and has compelling pros and cons when compared even with commercial OSes. Bluetooth will probably work out of the box, and getting low latency "Pro" audio routing features without breaking your desktop audio no longer requires a bunch of specialized knowledge; nominally, it's a dropdown in your audio settings. That having been said... You may face some issues, especially with cutting-edge motherboards and laptops. In general, Linux does not adequately support laptops that need a lot of software DSP in the driver to sound good. In addition, some of the more advanced audio codec setups may not work correctly out of the box. This is NOT the case for the majority of desktop motherboards, but it is worth googling to see if you can find someone reporting that it works. Software: There is a lot of heated debates about what the best distro and desktop environments are. Normally, I'd recommend sticking with a stalwart like Debian, but in this changing environment I'm really not sure what I'd personally recommend. I run NixOS, which I think is a fantastic operating system for people who know they need it, but like Linux itself, I would not recommend it to anyone unless they're relatively sure it's something that solves a problem they actually have. I pretty much knew immediately I wanted it when I heard about it. But even when not considering NixOS, I strongly would recommend trying to find an "immutable" Linux distro that will work for you. This is because immutable Linux has proven to be a much better model for desktop usage that is far more robust and easier to reason about. A good example would be Fedora Silverblue. There was a nice looking project on here recently that may be of particular interest to developers, based on Silverblue, called Bluefin: https://projectbluefin.io/ https://projectbluefin.io/ I can't necessarily personally recommend it, but the concept seems solid. Recommending a random recent project is a little risky, but it at least has the benefit that it's essentially just a spin of Silverblue that can be reverted back to plain old Silverblue safely as far as I know. My personal choice for a desktop environment is none. I use SwayWM with a bunch of bespoke configuration. It's... ugly[1]. But it works, and for me, it works quite well. But that is a horrible recommendation for someone who is trying to get into Linux by any measure. Instead, I recommend KDE. KDE has a fair amount of stability issues, but what I can say about KDE is that it's got a great balance of customization, features and polish for a desktop system, and I think that the current iteration of KDE is going to age well into the future. We'll see how that thought holds up, but I have my hopes. If you are using an AMD card, I can also say that running KDE/Plasma Desktop in Wayland mode is a pretty good experience, if you can. It does come with some challenges and downsides, but there are some positives, especially if you like high DPI or high refresh rate screens, or you want to use OBS to capture or stream the screen, as it will be a lot more efficient using Pipewire on Wayland. At the very least, it's not a huge commitment since you can log out and jump back in with an X11 session through your display manager if anything goes too wrong. P.S.: While I don't immediately recommend anyone to go and try NixOS, I can't say the same about Nix. Go and install Nix on your macOS or Linux machines! It's a great tool to have and is generally not obtrusive on a machine. Especially see the `nix develop` command. It drops you in a shell with the development tools used to build a package, so I can do say, `nix develop nixpkgs#_86Box` to get all of the dependencies to build the 86Box emulator, and just start building it with CMake. [1]: https://github.com/jchv/nixos-config/tree/master/modules/programs/sway https://github.com/jchv/nixos-config/tree/master/modules/pro... - In case anyone is curious about a "real world" Sway setup, this certainly is one. In the back of my mind, I'm secretly hoping someone will suggest improvements. :)

JonChesterfield 3y ago

This is exciting. I don't know what it is but I am thrilled that more things associated with Xilinx are showing up in Linux. Can anyone add some context beyond the post as to what this is?

pella 3y ago

--> https://github.com/amd/xdna-driver https://github.com/amd/xdna-driver

angm128 3y ago
"To run AI applications (test machine): RyzenAI processor, example: Phoenix/Strix" Is there any strix besides the unreleased Strix Point and Strix Halo?
- adrian_b 3y ago
  No. However the AMD CEO has confirmed recently that Strix Point (laptop Zen 5) will be released later this year (and it is currently being tested by AMD partners like Microsoft) and that it will include a NPU much faster than that of Hawk Point (Ryzen 8040 series) and Phoenix (Ryzen 7040 series). As Strix Point is currently in testing at external partners, they must have at least preliminary versions of the software for it.

shmerl 3y ago

Hopefully the plan is to upstream it.

im3w1l 3y ago

So what functionality does Ryzen AI have? I couldn't get past the marketing copy while trying to find it.

p_l 3y ago
It's a 4x4 configuration of the separately available Xilinx/AMD AIE-ML accelerator, available on Xilinx alveo platform IIRC. VLIW vector units optimized for AI (-ML suffix) with runtime reconfigurable network on a chip letting you optimize "streaming" the data between individual cores. The way "AMD IPU" device was implemented, which embeds the system in some new AMD CPUs, the previous drivers (which were Linux/RTOS only) didn't work. I was actually in the middle of reverse engineering how it was exposed in Phoenix (7940hs) APUs to write custom driver for Linux based on the one shipped for windows.
- 3abiton 3y ago
  How does it compare to cuda in terms of versatility and compatibility? most AI frameworks are built around cuda (pytorch, etc..) which is why nvidia has a monopoly now, I fail to see AMD breaking through, but one can hope. Do you see a light at the end of the tunnel?
  - p_l 3y ago
    It's targeting the high power efficiency part of the spectrum where nvidia is much less available. There's some reasonably capable software support, in fact the linux driver linked is significantly more capable than the "SDK" they released so far for windows. Which makes sense, because under Xilinx brand they have been selling accelerators and SoCs using AIE and AIE-ML cores for various use cases in embedded world, and XRT lets you program those with pretty much plain C++. For some AI tasks, they have provided high-end wrappers for models that use ONNX (iirc) so those can be used immediately. This is not ROCm, and has essentially none of the ROCm bullshit in terms of support. I seem to recall there's some work to integrate parts of ROCm (opencl, HIP) with XRT. Definitely going to build some kernels with this and test drive it ASAP.
3y ago

sva_ 3y ago

Seems like RDNA3 is not supported.

wmf 3y ago
You use ROCm drivers for RDNA3 and XRT drivers for XDNA.
shmerl 3y ago
Isn't it an ASIC on the CPU? What does that have to do with RDNA3?
p_l 3y ago
It's a completely separate accelerator code, though there's possibility of maybe using it in combined fashion with HIP/ROCm OpenCL (I think there's OpenCL compiler for AIE and AIE-ML, but I'm not sure at how well it works yet)
- sva_ 3y ago
  Ah, I wasn't really aware that there is a separate accelerator in the 7040 series, other than rdna3's wmma.
  - p_l 3y ago
    Yeah, it's Xilinx AIE, stuff that was already supported on Linux - but it was differently connected on 7040: the AIE module being connected direct to Infinity Fabric, masquerading as PCIE device, instead of existing PCIE driver which assumed mediation done by on-fpga CPU etc. At least that's how it looked from what I've read in XRT docs so far. This driver both provides necessary interface in place of an ARM core talking direct over AXI buses, and the glue logic to enable use of XRT.