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...
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.
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 ;-)
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.
If the new 3rd generation Ryzen stuff ends up being as good as it looks, then I'd say we're in for a good year as far as mobile AMD hardware's concerned. There's a good chance that you have nothing to worry about as far as upgrade paths are considered.
I hope so, but my current laptop has a desktop-class Ryzen 7 1700 in it and their mobile offerings usually come with half as many cores, but I guess we'll see what Ryzen 3 has to offer.
Well Nvidia is better with closed source drivers than AMD with open source, having open source driver means nothing in term of driver quality, what matters is how many people are working on it and for Nvidia there are much much more people working on it because Nvidia is very popular outside of gaming on Linux.
I had the opposite experience. I had an older nvidia card. The binary driver would work great, then an update to the nvidia driver would come out, and the next reboot, I got to have lots of fun trying to get get it repaired without a gui. Half the time, just uninstalling/re-installing the older version would fix it.
For a long time I was on Ubuntu 14.04 LTS with the NVidia driver, and every time to update it would be a pain; inevitably, when I rebooted, I'd be at a console, having to fix the damn thing so the updated driver would work.
After a couple of times of this, what I saw that was happening (and I am not saying this was it in your case) was my X config file was being replaced/updated and really just breaking everything. So I got in the habit of always making a backup of that file. Usually, when dropped at the console, I could just backup the config file there, then copy my old file over, and everything would work perfectly on restart.
Except this last time (a few months ago) - but it was inevitable it would happen, and it was entirely my fault.
I had a need a couple of years back to be able to use the latest C++ 11 version of gcc - but 14.04 LTS didn't have it available, and there wasn't any backports. So I decided to "wing it" from scratch, compiling a new version.
Then I found myself in dependency hell - which I also got past through a variety of updates from for my Ubuntu, or via download and install, etc. It was a complete mess, but in the end I got it working...
...until I tried to update - the entire update system was fairly broken, so no moving forward from 14.04 LTS.
But I thought I could do NVidia's latest proprietary driver - and it needed the compiler and other parts (for what reason I don't know) and it died a horrible death, leaving me with no good options to for the driver. I had to fall back to the open source neuveau driver (yuck) just to get my desktop back. But things were pretty well hosed.
Fortunately my OS was on a seperate partition and drive, so I bit the bullet and did a reinstall and upgrade (to Budgie Desktop 18.04 LTS), and vowed to never do any hand compile and install stuff again (next time if I need such a thing, it's going to be in a VM or containerized).
I've often wondered about putting the whole of /etc into a git repository, so any changes (either by software updates, or by myself) were visible and reversible. Does anyone do this, and if not why not?
The NVidia driver is a crapshoot though. I have massive problems with it on my desktop and none at all on my laptop. I have had more consistently good experiences with AMD.
My experience with AMD open drivers has been great. I had an HD 6850 before, new system with an RX 580, both have worked great. Had a few issues with the 6850 earlier on, but nothing too bad like you've described.
I thought it was interesting how they began forcing Windows users through a login page to associate identity, and a continuous background telemetry service, but not Linux users. The telemetry service needs to be running just to check for updates to the gaming card drivers.
At least, I personally didn't have that experience on Linux with proprietary driver when the Windows gaming rig did. They likely determined it wasn't worth the effort or Linux users would be more likely to lash back at the intrusion. Or it could have been a later target but still on their plan..
Have they changed this and forced their telemetry collection onto the Linux desktop yet?
I doubt they'd prereq it to install drivers for their ML or workstation cards. I'm a little more worried about their gaming/desktop cards.
Except it's not accessible to 90% of users because it's only delivered as a single package that installs both of them in combination. If you decline their telemetry service, it does not install the driver.
If you want to install just the driver, you have to extract the driver from their executable and manually handle updates, or use a third party package manager like chocolatey.
Most people won't know this is possible. The trade-off to the vast majority is to trade unknown bits of their information for security and stability updates.
Should that really be the default state of things?
It seems that everyone has a different experience on the subject! Just a precision: I had an ATI card (laptop) from 2005 to 2010, then an ATI (desktop) from 2010 to 2017.
I've been exclusively buying AMD discrete graphics for the better part of a decade since they started developing their open driver.
Between a 4850, 7870, 290, and 580 I've been a satisfied customer. It was rough waters in 2012, but nowadays its flawless.
On the CPU side though... I do want to make a big upgrade this year. I've had a 4770k since release. 8 cores sounds pretty juicy. But AMD still has their proprietary PSP and unlike with the Intel ME I have no way to disable it. While it sucks giving Intel money when they have been no help disabling their government backdoor into my computer the fact the community has disabled it (assuming ME cleaner will work properly on whatever Intel CPUs come out this year) makes me lean towards buying another Intel chip. Not because I want to support them, but because AMD hasn't given me an alternative yet.
The sad truth is that it takes a while for the open source drivers to solidify after any new release and going open source means not getting the newest hardware.
Well, Intel actually seems to get their open source driver support in far enough ahead of time these days that you can just load the newest Ubuntu with them and it works, but that wasn't the case 5 years ago.
AMD's almost there, you can just install 18.10 and Steam and go gaming with nothing else to install. 18.04 not so much, but once distros start shipping with newer kernels/mesa then it should sort itself out.
Most people don't care about having the newest hardware. The only cases that come to my mind are hardcore pc gamers, people who edit video, and people doing deep learning.
Maybe this is true for desktop PCs, but in my case I always had to be very careful when buying a new laptop/notebook (which basically always had the newest HW because it just came with it).
true. and still, intel drivers are a landmine. even the latest ones shipped today generates FIFO warnings because of the bad code. Not to mention itel "graphic cards" are a glorified floating point co-coprocessor and the "drivers" just rename mesa-software with intelgfx or something :) man, everything about intel lately feels like a joke you remove the marketing lacquer... it's almost if they are the IBM of old.
anyway, but AMD have actual graphics cards, and the driver quality they open source is usually very good.
I built new media box last year and thought I would try AMD Ryzen 2400G APU. Turns out it was a bad choice. Those graphics drivers are extremely unstable, it keeps crashing frequently, kernel bug reports have many reports from multiple people with info on how to reproduce them but those cases are still in status "NEW" almost 1 year later.
And while their Windows benchmarks are decent, anything 3D related on Linux is a glitching disaster with poor performance.
My friend bought latest Intel NUC with AMD Vega graphics and he could not even get Linux to boot with that.
Meanwhile I have Nvidia GTX970 on my desktop PC and everything works fine, even G-Sync works. I have used Nvidia cards with Linux for 10 years now and I have not had any issues like I have with AMD now.
To me it seems like AMD dumping their drivers as open source is a call for help on maintaining them rather than being all friendly to community.
Yet I can still not read CPU core temperatures of my ryzen 2600 on Linux (5.0-rc2). I am not sure what is going on but I think next time I'll go with Intel again. I read this may be related to some NDA by AMD but not sure.
Temperature monitoring for the first gen Ryzen chips has been in the kernel for about a year. The patch for second gen is there but narrowly missed the 5.0 release window, so it should land in the first release after 5.0.
Intel is a bit faster about this but it's not like they have perfect day 1 kernel support either. i.e. temperature monitoring drivers for both first gen Ryzen and Coffee Lake landed in 4.15. At the time Ryzen was almost a year old and Coffee Lake was about half a year old.
Based on personal experience temperature monitoring on Coffee Lake worked just fine with 4.14. I'm pretty sure there hasn't been a breaking change in Intel's interface for this since at least Sandy Bridge.
I just Googled "ryzen temperature monitoring linux".
I've had a Ryzen 1700 since they first came out so I was following the Linux support for that fairly closely at the time, mostly by browsing Phoronix fairly frequently. Thankfully after a few months I didn't need to because things were working pretty well by then, other than the thermal monitoring that took quite a while to land. Linux and brand new hardware rarely seem to get along well regardless of the vendor unfortunately.
Perhaps someone could just reverse engineer what the Windows driver does to get the values.
It could be a nice way to learn a tool like Binary Ninja or IDA (pro).
It's probably some DeviceIoControl call. Once you know the call 12-bit (I think?) ID from userland code, it should be relatively straightforward to follow the driver code to see where it ends up and what hardware registers it uses.
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...