30 ms·

AMD Open Source Driver for Vulkan

505 points by ajr0 8y ago

notus 8y ago
It seems like this repo has existed for over a year and no commits within the past couple days, I'm not sure what the discussion is supposed to be about when there is just a link to a repo.
- boudin 8y ago
  Indeed, AMDVLK was part of the AMDGPU pro driver first and was opensourced in december 2017, so it's not new.
  - Macha 8y ago
    I guess it's in the context of the Proton/Linux gaming discussions earlier.
turblety 8y ago
So does anyone know now if AMD Vulkan GPU's are fully open sourced? i.e. can we build everything from source, firmware, drivers, app and then use it without having to trust any blobs?
- boudin 8y ago
  Firmware isn't opensource. Kernel and userland drivers are. There's RADV as an alternative to AMDVLK which was created while AMDVLK was closed source. Both are maintained.
  - zepearl 8y ago
    But it's correct to say that the firmware used under Linux is the same one that is used as well under Windows (maybe as well MacOS)... or not? (I personally understand that the "firmware" does the low-level stuff, and the drivers of the OS provide the abstraction through their functions, but I might be terribly wrong)
    - woodrowbarlow 8y ago
      yes, the firmware is the same regardless of your OS. think of it like using an open-source client for slack: it still hits the API of a closed blob (the slack servers).
      - zepearl 8y ago
        Thx! Then, if the performance is "worse" or "better" for a specific OS, it's just because the code of the open-source part (kernel and/or userland progs) and/or the app (game/application/whatever) is not written as well as on the other OSs, right? Indirectly asking as well: even if the firmware is alway the same one, there is no "part" of the firmware that is dedicated to only a specific OS?
        boudin 8y ago
        Performance-wise yes, logicaly the difference would come from the driver part. For the firmware, it's hard to know, i think only someone from AMD can answer this. It's technically possible if part of a firmware is used only by the Windows driver for example. After, I have no idea, if it's the case...
        woodrowbarlow 8y ago
        performance differences come down to how the driver utilizes the firmware, or how the applications utilize the driver. there may be some other factors, like how the OS manages memory buffers. it's unlikely that the firmware has OS-specific code. it's more likely that the firmware exposes functionality that happens to be taken advantage of by one OS' drivers more than it is by another OS' drivers -- perhaps in part because of differences in driver execution models on different kernels. or sometimes (as with nvidia) because a proprietary closed-source windows driver was written by the company with access to private documentation of all the firmware's features while the community-written linux OSS driver was written with incomplete knowledge of the firmware's features derived from reverse engineering.
  - makomk 8y ago
    One of the obnoxious consequences of the firmware not being open source is that, even though both RADV and AMDVLK support GPUs as far back as the 7xxx series, the AMDGPU driver required to use them can't be enabled by default. The released firmware for the UVD video decode unit doesn't support the framebuffer addresses used by AMDGPU, meaning that it can't support hardware video decode until they release an up-to-date firmware: https://lists.freedesktop.org/archives/amd-gfx/2017-November/015795.html https://lists.freedesktop.org/archives/amd-gfx/2017-November... So far users have been waiting for over a year and heard only silence. I suspect, given their attitude to older hardware, the required firmware will never be released.
- vardump 8y ago
  I think open source GPU firmware will be very unlikely to happen for any high-performance part in the near-medium term future.
- monocasa 8y ago
  Some of the firmware has been reverse engineered, with community supplied patches, but that's not supported at all by AMD. https://github.com/fail0verflow/radeon-tools/tree/master/f32 https://github.com/fail0verflow/radeon-tools/tree/master/f32 What's interesting is there's not a clear reason for the firmware to not be opened other than it's probably a huge amount of work to document. It looks like an unexpected house design so there shouldn't be IP issues, and it's pretty mundane stuff so there shouldn't be trade secret issues either. : /
  - rhn_mk1 8y ago
    That has actually been discussed by an AMD employee [0]. Commentary [1]. [0] https://www.reddit.com/r/Amd/comments/950g8r/will_we_be_able_to_game_anytime_soon_using_amd/e3qgqp3/ https://www.reddit.com/r/Amd/comments/950g8r/will_we_be_able... [1] https://www.reddit.com/r/linux/comments/95romz/ubridgmanamd_an_amd_employee_commented_on_the/ https://www.reddit.com/r/linux/comments/95romz/ubridgmanamd_...
    - Hackbraten 8y ago
      I always knew bibliographies started at 0!
    - monocasa 8y ago
      A lot of that falls flat. Part of what he's saying is in regard to signed updates, but the microcode on at least some pretty new chips isn't signed, as the fail0verflow guys were able to patch it.
- bayindirh 8y ago
  AMD beta tester here. AMD separated HDCP and DRM related silicon from video acceleration units some time ago to be able to open source their GPUs completely sans the NDA bound stuff. Even this is a very big generosity and step from them for the Linux community. I'm sure that the firmware contains some highly proprietary and revealing information about some of their secret sauce. So, they won't be able to do it even if they want to.
  - novaRom 8y ago
    What HDL is in use at AMD - Verilog like at Nvidia or SystemC like at Intel?
    - bayindirh 8y ago
      Sorry, that's beyond my knowledge.
  - shmerl 8y ago
    There is no secret sauce in the firmware, but it has HDCP garbage (which is causing it to remain a blob). AMD could provide one without HDCP as an open option, but I suppose they didn't see enough demand for it.
    - bayindirh 8y ago
      I think it also had the clocks, memory settings, thermal thresholds and other hardware tuning parameters. So opening the firmware may also lead to many many fried boards. Also, if the core enablement and configuration is done in the firmware, some vendors may find themselves in a hard position, since they may be selling crippled GPUs as lower spec cards. Last, but not the least if folks enable faulty CUs in their cards and see the faults, they may create some (albeit unjustified) noise in "teh internets", which will return as bad press. So, while the firmware is good for research and educational purposes, it's also a Pandora's box IMHO.
      - shmerl 8y ago
vorpalhex 8y ago
I'm glad AMD has consistently put in work to keep their drivers available to the Linux community, even if sometimes it's been less than perfect. I really hope that Nvidia eventually also open sources it's drivers.
- chme 8y ago
  Nvidia will properly never do that. Since they don't see themselves as just hardware manufacturers. They want to bind customers to their hardware and cause them to buy newer hardware versions in high frequency and there seems to be no better way to do that than via software that they can artificially age if need be and lock to prevent alternative solutions.
- xvilka 8y ago
  When hell freezes over. Their management seems stuck to agressive anti-FOSS stance forever. Shame to every developer who works for them - it is like working for the evil.
  - beatgammit 8y ago
    I keep wondering where Oracle and Nvidia come up with their developers. I don't want to work at either because of their complete disregard for FOSS, and most developers I know have the same opinion.
    - mj_olnir 8y ago
      Salary. Remember, Comcast also has software developers.
      - kkarakk 8y ago
        also there are a lot of developers globally with looser morals because of different cultural values. in my experience anyone from a -stan country will make whatever you want as long as you give them a decent salary and a visa
tombert 8y ago
I can't speak for anyone else, but because AMD has been opening up their drivers, the laptop I purchased six months ago was AMD based. I haven't done any kind of elaborate benchmarks, but as someone who runs Linux full-time, I want to support companies that make my life a bit easier. That said, I have had some issue with my computer having some weird graphical glitches, and then crashing...I don't know if that's the drivers fault but I never had this with my NVidia or Intel cards...
- dpwm 8y ago
  October 2016 I built an AMD-based desktop with integrated GPU. I was seriously impressed at the out-the-box support in Linux compared with the support for their earlier chipsets. I seem to remember at around the same time that the Intel open source drivers went through a number of regressions. In the past I've had really bad experiences with ATI's GPUs. My 2016 experience would certainly allay my fears about buying AMD.
- tatref 8y ago
  I supported AMD several years because of this... Then I got tired of the low quality of both the open source, and the closed driver. Crashes, glitches in movies, flickering... Some time ago, I bought an Nvidia. It works like charm with the closed driver on Linux and windows. I do mainly games on Linux/windows, some gpgpu (machine learning with tensor flow), and the usual stuff. I couldn't be happier... Except if it was open source ;-)
  - AsyncAwait 8y ago
    I purchased an AMD laptop precisely because I got tired of having to deal with NVidia, ether their glitchy proprietary driver breaking GNOME every so often, or Optimus being a pain via Bumblebee. Since switching to the AMD laptop, my experience has been smooth. My only worry is the upgrade path, there aren't that many high-performance AMD laptops out there and my next purchase is definitely AMD.
    - Thaxll 8y ago
charliebrownau 8y ago
I will be giving Linux another go with R9 380 with Kernel 5.1 later this year I gave Linux a go for 2 months in 2018 over 11 different distros, in the end I reverted back to Windows 7 AMDGPUPRO Driver - * Best FPS , 70-80fps in most games * no control panel centre * only worked with frist screen (27" HDMI+19" VGA) * no wattman Open source driver * Worked on both screens * NO HDMI audio * Sub 60fps fps * no control panel for settings
mrweasel 8y ago
Sadly I constantly hear people say that you should get an Nvidia card for both Linux and FreeBSD, because the drivers are better. While I'm sure that Nvidias driver a good, it's kinda sad that the attitude is that AMD is a better friend of the open source community, but yeah, we're going with Nvidia. I get why, you have stuff to do and Nvidia performs better, but still it a little annoying. OpenBSD seems to be the only open source operating system that suggests that you get an AMD card (or use Intel integrated graphics).
- crazysim 8y ago
  What about Linus giving the finger to Nvidia? I'm pretty sure that's a suggestion of some sort.
  - dijit 8y ago
    they seem to be difficult to work with as a company, but their desktop GPUs seem to mostly "just work" on Linux/FreeBSD - so for the user they seem to be better.
- floatboth 8y ago
  FreeBSD is definitely better with AMD. No one should be recommending nvidia in 2019. There is unfortunately a little boot issue currently (amdgpu conflicts with the EFI framebuffer, so when booting with UEFI you have to turn efifb off, resulting in no display after the bootloader and until the GPU driver loads). But other than that, I'm very happy with amdgpu & Mesa.
- chme 8y ago
  You mean the proprietary Nvidia driver? Because( no offense to the nouveau guys, you do great job, all things considered) but the open source one is in pretty bad shape and that is completely the fault of Nvidia. Having to extra compile their driver (that does not conform to kernel standards) delivers a subpar experience for Linux users and taints the kernel. If they don't care about Linux users and help develop the open source driver, they I don't see any reason for buying their hardware. I rather spend it on hardware manufacturers that try to support me as a customer.
joshuarubin 8y ago
Nvidia refuses to support GBM for Wayland and instead came out with a completely different buffer API, EGLStreams. This is pretty arrogant. As I use sway, and it doesn't support Nvidia, I chose an AMD Vega 64, which works great. https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
- beatgammit 8y ago
  How do you like sway? I'm still on an Nvidia GPU, but I might upgrade this year to an AMD GPU, and I've been hesitant to get back into tiling window managers untill I can use one on Wayland.
  - joshuarubin 8y ago
    Love it. That said, the 3rd party application support for wayland is pretty poor. Chrom(ium|e) can’t even do accelerated video under XWayland (so everything is choppy, even on my threadripper system). Firefox is better, but still uses XWayland. Wayland support is available in Firefox nightlies, but it _really_ isn’t ready for daily use yet. For the most part everything works fine, but I’m anxious for native wayland support from many apps (Electron apps in particular).
newnewpdro 8y ago
The more people support AMD by buying their hardware, the better the drivers will become. Obviously we should support the more open of the options, it's not like AMD can't deliver satisfactory hardware.
- ab5tract 8y ago
  “But mah FPS!!” I have never understood the relative lack of loyalty amongst nerds. Demand more FLOSS, but buy NVIDIA for a few frames per second. Use Chrome instead of Firefox for a few milliseconds on render. Rejoice at clang while maintaining that GCC never did anything good for anybody. The whole point of libre software is that the choice of what you use matters, but I rarely see ethical considerations trump hot rodding.
novaRom 8y ago
I have recently moved my home PC to latest AMD APU (latest Athlon). No CPU Fan because it's passive, no proprietary closed source binary blobs anymore because AMD open source drivers work out of the box (latest Ubuntu).
novaRom 8y ago
Nvidia will be forced to do the same pretty much soon. The real thread for this oligopoly (AMD, Nvidia) will be from Asia. Look what's happening with SoCs in mobile phones in general and project it to all different types of silicon including dedicated accelerators.
cr0sh 8y ago
I'd love to try AMD video cards again, but what's recently held me back is that I sometimes play around with stuff like Tensorflow and other ML libraries. They all seem to be geared toward CUDA, which of course is an NVidia only thing. I've never really looked deeply into it, but are there performant options, close to CUDA, that would allow me or others to use such ML libraries on AMD GPUs?
- montalbano 8y ago
  Tensorflow has a working AMD fork: https://github.com/ROCmSoftwarePlatform/tensorflow-upstream https://github.com/ROCmSoftwarePlatform/tensorflow-upstream See following links for more discussion: https://www.reddit.com/r/MachineLearning/comments/85iwyj/d_tensorflow_with_amd_gpu/ https://www.reddit.com/r/MachineLearning/comments/85iwyj/d_t... https://gpuopen.com/rocm-tensorflow-1-8-release/ https://gpuopen.com/rocm-tensorflow-1-8-release/ https://stackoverflow.com/questions/37892784/using-keras-tensorflow-with-amd-gpu https://stackoverflow.com/questions/37892784/using-keras-ten...
zanny 8y ago
A lot of people are talking along the lines of "oh AMD is nice but... Nvidia". No, in 2019 all AMD GPUs this decade support OpenGL through 4.5, support Vulkan, and still really don't have a great OpenCL situation (rocm is out of tree on every distro and only supprts parts of 2.0 still). For gaming though, theres no reason not to get an AMD GPU. They are at near performance parity with Nvidia relative to their Windows performance, they work with the inbuilt drivers on every distro out of the box, and the only footgun to watch out for is that new hardware generally takes a feature release Mesa cycle to get stable after launch. You even get hardware accelerated h264 encoding and decoding (and vpx on some chips) via vaapi. All on top of the fundamental that they are much more freedom respecting than Nvidia. Stop giving Nvidia your money to screw you over with. CUDA, their RTX crap, Gsync, Physx, Nvidia "Gameworks", and much more are all anti-competitive monopolist exploitative user-hostile evil meant to screw over competition and customers alike. Nvidia is one of the most reprehensible companies out there among peers like Oracle. AMD isn't a selfless helpless angel of a company, but when their products are competitive, and in many ways better (such as supporting Wayland) stop giving such a hostile business your money.
- dragontamer 8y ago
  > No, in 2019 all AMD GPUs this decade support OpenGL through 4.5, support Vulkan, and still really don't have a great OpenCL situation (rocm is out of tree on every distro and only supprts parts of 2.0 still). To be fair, only Intel has good OpenCL 2.0+ support. NVidia isn't really pushing OpenCL and AMD's ROCm OpenCL driver is still a bit unstable. AMD's OpenCL 2.0 support has always been poor. The Windows OpenCL 2.0 stuff didn't have a debugger for example, it really wasn't a good development environment at all. Only OpenCL1.2 had a decent debugger, profilers, or analysis tools. Frankly, it seems like OpenCL2.0 as a whole is a failure. All the code I've personally seen is OpenCL 1.2. Intel is pushing ICC / autovectorization, NVidia is pushing CUDA, and AMD was pushing HSA, and maybe now HCC / HIP / ROCm. No company wants to champion OpenCL 2.0. Video Games are written in Vulkan Shaders, DirectX shaders, or GLSL. They exist independently of the dedicated compute (CUDA / OpenCL) world. CUDA, OpenMP 4.5 device offload, and ROC / HIP / HCC are the compute solutions that seem to have the best chances in the future... since OpenCL 2.0 is just kinda blah. AMD's ROCm stack still needs more development, but it does seem to be improving steadily. ---------- I know everyone wants to just hold hands, sing Kumbaya and load SYCL -> OpenCL -> SPIR-V neutral code on everyone's GPUs, but that's just not how the world works right now. And I have my doubts that it will ever be a valid path forward. The hidden message is that CUDA -> CLang -> NVidia is a partially shared stack with HCC -> CLang -> AMD. So LLVM seems to be the common denominator.
shmerl 8y ago
I build amdvlk periodically to test. They didn't yet release VK_EXT_transform_feedback. radv (AMD Vulkan driver by Mesa project) already has it. It's an important feature for projects like dxvk. See http://jason-blog.jlekstrand.net/2018/10/transform-feedback-is-terrible-so-why.html http://jason-blog.jlekstrand.net/2018/10/transform-feedback-...
snickerbockers 8y ago
Maybe there's something I'm missing here, but that github repo doesn't appear to have any code...?
- 0gz 8y ago
  https://github.com/GPUOpen-Drivers https://github.com/GPUOpen-Drivers

505 points by ajr0 8y ago

It seems like this repo has existed for over a year and no commits within the past couple days, I'm not sure what the discussion is supposed to be about when there is just a link to a repo.

boudin 8y ago
Indeed, AMDVLK was part of the AMDGPU pro driver first and was opensourced in december 2017, so it's not new.
- Macha 8y ago
  I guess it's in the context of the Proton/Linux gaming discussions earlier.

turblety 8y ago

So does anyone know now if AMD Vulkan GPU's are fully open sourced? i.e. can we build everything from source, firmware, drivers, app and then use it without having to trust any blobs?

boudin 8y ago
Firmware isn't opensource. Kernel and userland drivers are. There's RADV as an alternative to AMDVLK which was created while AMDVLK was closed source. Both are maintained.
- zepearl 8y ago
  But it's correct to say that the firmware used under Linux is the same one that is used as well under Windows (maybe as well MacOS)... or not? (I personally understand that the "firmware" does the low-level stuff, and the drivers of the OS provide the abstraction through their functions, but I might be terribly wrong)
  - woodrowbarlow 8y ago
    yes, the firmware is the same regardless of your OS. think of it like using an open-source client for slack: it still hits the API of a closed blob (the slack servers).
    - zepearl 8y ago
      Thx! Then, if the performance is "worse" or "better" for a specific OS, it's just because the code of the open-source part (kernel and/or userland progs) and/or the app (game/application/whatever) is not written as well as on the other OSs, right? Indirectly asking as well: even if the firmware is alway the same one, there is no "part" of the firmware that is dedicated to only a specific OS?
      - boudin 8y ago
        Performance-wise yes, logicaly the difference would come from the driver part. For the firmware, it's hard to know, i think only someone from AMD can answer this. It's technically possible if part of a firmware is used only by the Windows driver for example. After, I have no idea, if it's the case...
      - woodrowbarlow 8y ago
        performance differences come down to how the driver utilizes the firmware, or how the applications utilize the driver. there may be some other factors, like how the OS manages memory buffers. it's unlikely that the firmware has OS-specific code. it's more likely that the firmware exposes functionality that happens to be taken advantage of by one OS' drivers more than it is by another OS' drivers -- perhaps in part because of differences in driver execution models on different kernels. or sometimes (as with nvidia) because a proprietary closed-source windows driver was written by the company with access to private documentation of all the firmware's features while the community-written linux OSS driver was written with incomplete knowledge of the firmware's features derived from reverse engineering.
- makomk 8y ago
  One of the obnoxious consequences of the firmware not being open source is that, even though both RADV and AMDVLK support GPUs as far back as the 7xxx series, the AMDGPU driver required to use them can't be enabled by default. The released firmware for the UVD video decode unit doesn't support the framebuffer addresses used by AMDGPU, meaning that it can't support hardware video decode until they release an up-to-date firmware: https://lists.freedesktop.org/archives/amd-gfx/2017-November/015795.html https://lists.freedesktop.org/archives/amd-gfx/2017-November... So far users have been waiting for over a year and heard only silence. I suspect, given their attitude to older hardware, the required firmware will never be released.
vardump 8y ago
I think open source GPU firmware will be very unlikely to happen for any high-performance part in the near-medium term future.
monocasa 8y ago
Some of the firmware has been reverse engineered, with community supplied patches, but that's not supported at all by AMD. https://github.com/fail0verflow/radeon-tools/tree/master/f32 https://github.com/fail0verflow/radeon-tools/tree/master/f32 What's interesting is there's not a clear reason for the firmware to not be opened other than it's probably a huge amount of work to document. It looks like an unexpected house design so there shouldn't be IP issues, and it's pretty mundane stuff so there shouldn't be trade secret issues either. : /
- rhn_mk1 8y ago
  That has actually been discussed by an AMD employee [0]. Commentary [1]. [0] https://www.reddit.com/r/Amd/comments/950g8r/will_we_be_able_to_game_anytime_soon_using_amd/e3qgqp3/ https://www.reddit.com/r/Amd/comments/950g8r/will_we_be_able... [1] https://www.reddit.com/r/linux/comments/95romz/ubridgmanamd_an_amd_employee_commented_on_the/ https://www.reddit.com/r/linux/comments/95romz/ubridgmanamd_...
  - Hackbraten 8y ago
    I always knew bibliographies started at 0!
  - monocasa 8y ago
    A lot of that falls flat. Part of what he's saying is in regard to signed updates, but the microcode on at least some pretty new chips isn't signed, as the fail0verflow guys were able to patch it.
bayindirh 8y ago
AMD beta tester here. AMD separated HDCP and DRM related silicon from video acceleration units some time ago to be able to open source their GPUs completely sans the NDA bound stuff. Even this is a very big generosity and step from them for the Linux community. I'm sure that the firmware contains some highly proprietary and revealing information about some of their secret sauce. So, they won't be able to do it even if they want to.
- novaRom 8y ago
  What HDL is in use at AMD - Verilog like at Nvidia or SystemC like at Intel?
  - bayindirh 8y ago
    Sorry, that's beyond my knowledge.
- shmerl 8y ago
  There is no secret sauce in the firmware, but it has HDCP garbage (which is causing it to remain a blob). AMD could provide one without HDCP as an open option, but I suppose they didn't see enough demand for it.
  - bayindirh 8y ago
    I think it also had the clocks, memory settings, thermal thresholds and other hardware tuning parameters. So opening the firmware may also lead to many many fried boards. Also, if the core enablement and configuration is done in the firmware, some vendors may find themselves in a hard position, since they may be selling crippled GPUs as lower spec cards. Last, but not the least if folks enable faulty CUs in their cards and see the faults, they may create some (albeit unjustified) noise in "teh internets", which will return as bad press. So, while the firmware is good for research and educational purposes, it's also a Pandora's box IMHO.
    - shmerl 8y ago

vorpalhex 8y ago

I'm glad AMD has consistently put in work to keep their drivers available to the Linux community, even if sometimes it's been less than perfect. I really hope that Nvidia eventually also open sources it's drivers.

chme 8y ago
Nvidia will properly never do that. Since they don't see themselves as just hardware manufacturers. They want to bind customers to their hardware and cause them to buy newer hardware versions in high frequency and there seems to be no better way to do that than via software that they can artificially age if need be and lock to prevent alternative solutions.
xvilka 8y ago
When hell freezes over. Their management seems stuck to agressive anti-FOSS stance forever. Shame to every developer who works for them - it is like working for the evil.
- beatgammit 8y ago
  I keep wondering where Oracle and Nvidia come up with their developers. I don't want to work at either because of their complete disregard for FOSS, and most developers I know have the same opinion.
  - mj_olnir 8y ago
    Salary. Remember, Comcast also has software developers.
    - kkarakk 8y ago
      also there are a lot of developers globally with looser morals because of different cultural values. in my experience anyone from a -stan country will make whatever you want as long as you give them a decent salary and a visa

tombert 8y ago

I can't speak for anyone else, but because AMD has been opening up their drivers, the laptop I purchased six months ago was AMD based. I haven't done any kind of elaborate benchmarks, but as someone who runs Linux full-time, I want to support companies that make my life a bit easier. That said, I have had some issue with my computer having some weird graphical glitches, and then crashing...I don't know if that's the drivers fault but I never had this with my NVidia or Intel cards...

dpwm 8y ago
October 2016 I built an AMD-based desktop with integrated GPU. I was seriously impressed at the out-the-box support in Linux compared with the support for their earlier chipsets. I seem to remember at around the same time that the Intel open source drivers went through a number of regressions. In the past I've had really bad experiences with ATI's GPUs. My 2016 experience would certainly allay my fears about buying AMD.
tatref 8y ago
I supported AMD several years because of this... Then I got tired of the low quality of both the open source, and the closed driver. Crashes, glitches in movies, flickering... Some time ago, I bought an Nvidia. It works like charm with the closed driver on Linux and windows. I do mainly games on Linux/windows, some gpgpu (machine learning with tensor flow), and the usual stuff. I couldn't be happier... Except if it was open source ;-)
- AsyncAwait 8y ago
  I purchased an AMD laptop precisely because I got tired of having to deal with NVidia, ether their glitchy proprietary driver breaking GNOME every so often, or Optimus being a pain via Bumblebee. Since switching to the AMD laptop, my experience has been smooth. My only worry is the upgrade path, there aren't that many high-performance AMD laptops out there and my next purchase is definitely AMD.
  - Thaxll 8y ago

charliebrownau 8y ago

I will be giving Linux another go with R9 380 with Kernel 5.1 later this year I gave Linux a go for 2 months in 2018 over 11 different distros, in the end I reverted back to Windows 7 AMDGPUPRO Driver - * Best FPS , 70-80fps in most games * no control panel centre * only worked with frist screen (27" HDMI+19" VGA) * no wattman Open source driver * Worked on both screens * NO HDMI audio * Sub 60fps fps * no control panel for settings

mrweasel 8y ago

Sadly I constantly hear people say that you should get an Nvidia card for both Linux and FreeBSD, because the drivers are better. While I'm sure that Nvidias driver a good, it's kinda sad that the attitude is that AMD is a better friend of the open source community, but yeah, we're going with Nvidia. I get why, you have stuff to do and Nvidia performs better, but still it a little annoying. OpenBSD seems to be the only open source operating system that suggests that you get an AMD card (or use Intel integrated graphics).

crazysim 8y ago
What about Linus giving the finger to Nvidia? I'm pretty sure that's a suggestion of some sort.
- dijit 8y ago
  they seem to be difficult to work with as a company, but their desktop GPUs seem to mostly "just work" on Linux/FreeBSD - so for the user they seem to be better.
floatboth 8y ago
FreeBSD is definitely better with AMD. No one should be recommending nvidia in 2019. There is unfortunately a little boot issue currently (amdgpu conflicts with the EFI framebuffer, so when booting with UEFI you have to turn efifb off, resulting in no display after the bootloader and until the GPU driver loads). But other than that, I'm very happy with amdgpu & Mesa.
chme 8y ago
You mean the proprietary Nvidia driver? Because( no offense to the nouveau guys, you do great job, all things considered) but the open source one is in pretty bad shape and that is completely the fault of Nvidia. Having to extra compile their driver (that does not conform to kernel standards) delivers a subpar experience for Linux users and taints the kernel. If they don't care about Linux users and help develop the open source driver, they I don't see any reason for buying their hardware. I rather spend it on hardware manufacturers that try to support me as a customer.

joshuarubin 8y ago

Nvidia refuses to support GBM for Wayland and instead came out with a completely different buffer API, EGLStreams. This is pretty arrogant. As I use sway, and it doesn't support Nvidia, I chose an AMD Vega 64, which works great. https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html

beatgammit 8y ago
How do you like sway? I'm still on an Nvidia GPU, but I might upgrade this year to an AMD GPU, and I've been hesitant to get back into tiling window managers untill I can use one on Wayland.
- joshuarubin 8y ago
  Love it. That said, the 3rd party application support for wayland is pretty poor. Chrom(ium|e) can’t even do accelerated video under XWayland (so everything is choppy, even on my threadripper system). Firefox is better, but still uses XWayland. Wayland support is available in Firefox nightlies, but it _really_ isn’t ready for daily use yet. For the most part everything works fine, but I’m anxious for native wayland support from many apps (Electron apps in particular).

newnewpdro 8y ago

The more people support AMD by buying their hardware, the better the drivers will become. Obviously we should support the more open of the options, it's not like AMD can't deliver satisfactory hardware.

ab5tract 8y ago
“But mah FPS!!” I have never understood the relative lack of loyalty amongst nerds. Demand more FLOSS, but buy NVIDIA for a few frames per second. Use Chrome instead of Firefox for a few milliseconds on render. Rejoice at clang while maintaining that GCC never did anything good for anybody. The whole point of libre software is that the choice of what you use matters, but I rarely see ethical considerations trump hot rodding.

novaRom 8y ago

I have recently moved my home PC to latest AMD APU (latest Athlon). No CPU Fan because it's passive, no proprietary closed source binary blobs anymore because AMD open source drivers work out of the box (latest Ubuntu).

novaRom 8y ago

Nvidia will be forced to do the same pretty much soon. The real thread for this oligopoly (AMD, Nvidia) will be from Asia. Look what's happening with SoCs in mobile phones in general and project it to all different types of silicon including dedicated accelerators.

cr0sh 8y ago

I'd love to try AMD video cards again, but what's recently held me back is that I sometimes play around with stuff like Tensorflow and other ML libraries. They all seem to be geared toward CUDA, which of course is an NVidia only thing. I've never really looked deeply into it, but are there performant options, close to CUDA, that would allow me or others to use such ML libraries on AMD GPUs?

montalbano 8y ago
Tensorflow has a working AMD fork: https://github.com/ROCmSoftwarePlatform/tensorflow-upstream https://github.com/ROCmSoftwarePlatform/tensorflow-upstream See following links for more discussion: https://www.reddit.com/r/MachineLearning/comments/85iwyj/d_tensorflow_with_amd_gpu/ https://www.reddit.com/r/MachineLearning/comments/85iwyj/d_t... https://gpuopen.com/rocm-tensorflow-1-8-release/ https://gpuopen.com/rocm-tensorflow-1-8-release/ https://stackoverflow.com/questions/37892784/using-keras-tensorflow-with-amd-gpu https://stackoverflow.com/questions/37892784/using-keras-ten...

zanny 8y ago

A lot of people are talking along the lines of "oh AMD is nice but... Nvidia". No, in 2019 all AMD GPUs this decade support OpenGL through 4.5, support Vulkan, and still really don't have a great OpenCL situation (rocm is out of tree on every distro and only supprts parts of 2.0 still). For gaming though, theres no reason not to get an AMD GPU. They are at near performance parity with Nvidia relative to their Windows performance, they work with the inbuilt drivers on every distro out of the box, and the only footgun to watch out for is that new hardware generally takes a feature release Mesa cycle to get stable after launch. You even get hardware accelerated h264 encoding and decoding (and vpx on some chips) via vaapi. All on top of the fundamental that they are much more freedom respecting than Nvidia. Stop giving Nvidia your money to screw you over with. CUDA, their RTX crap, Gsync, Physx, Nvidia "Gameworks", and much more are all anti-competitive monopolist exploitative user-hostile evil meant to screw over competition and customers alike. Nvidia is one of the most reprehensible companies out there among peers like Oracle. AMD isn't a selfless helpless angel of a company, but when their products are competitive, and in many ways better (such as supporting Wayland) stop giving such a hostile business your money.

dragontamer 8y ago
> No, in 2019 all AMD GPUs this decade support OpenGL through 4.5, support Vulkan, and still really don't have a great OpenCL situation (rocm is out of tree on every distro and only supprts parts of 2.0 still). To be fair, only Intel has good OpenCL 2.0+ support. NVidia isn't really pushing OpenCL and AMD's ROCm OpenCL driver is still a bit unstable. AMD's OpenCL 2.0 support has always been poor. The Windows OpenCL 2.0 stuff didn't have a debugger for example, it really wasn't a good development environment at all. Only OpenCL1.2 had a decent debugger, profilers, or analysis tools. Frankly, it seems like OpenCL2.0 as a whole is a failure. All the code I've personally seen is OpenCL 1.2. Intel is pushing ICC / autovectorization, NVidia is pushing CUDA, and AMD was pushing HSA, and maybe now HCC / HIP / ROCm. No company wants to champion OpenCL 2.0. Video Games are written in Vulkan Shaders, DirectX shaders, or GLSL. They exist independently of the dedicated compute (CUDA / OpenCL) world. CUDA, OpenMP 4.5 device offload, and ROC / HIP / HCC are the compute solutions that seem to have the best chances in the future... since OpenCL 2.0 is just kinda blah. AMD's ROCm stack still needs more development, but it does seem to be improving steadily. ---------- I know everyone wants to just hold hands, sing Kumbaya and load SYCL -> OpenCL -> SPIR-V neutral code on everyone's GPUs, but that's just not how the world works right now. And I have my doubts that it will ever be a valid path forward. The hidden message is that CUDA -> CLang -> NVidia is a partially shared stack with HCC -> CLang -> AMD. So LLVM seems to be the common denominator.

shmerl 8y ago

I build amdvlk periodically to test. They didn't yet release VK_EXT_transform_feedback. radv (AMD Vulkan driver by Mesa project) already has it. It's an important feature for projects like dxvk. See http://jason-blog.jlekstrand.net/2018/10/transform-feedback-is-terrible-so-why.html http://jason-blog.jlekstrand.net/2018/10/transform-feedback-...

snickerbockers 8y ago

Maybe there's something I'm missing here, but that github repo doesn't appear to have any code...?

0gz 8y ago
https://github.com/GPUOpen-Drivers https://github.com/GPUOpen-Drivers