Earlier this week I got my dirty hands on an RX Vega 64 card to run on my daily workstation. With the aim to eventually run open drivers in the future my main goal for now was to get AMDGPU-PRO running for day-to-day activities, possibly also moving to Wayland from X11. I’m very interested in Wayland as Kwin has several Wayland-only enhancements, and even if I wouldn’t use it now I wanted to be ready for testing.ย  The Vega card would be replacing an Nvidia GTX 1080 card.

In terms of usage I look to beefy video cards for when I do the odd video-related task, for applications like Krita, and other reasons up to and including general enthusiasm.

Since it’s been a pretty rough experience I figured I’d blog about the state of Vega with Plasma, my opinions, and my hopes for the future.


Because of the stock shortages which have been pretty persistent I ordered the standard edition sapphire card when I stumbled across one that somehow hadn’t sold out.

I like the understated design of it, and despite its more simple looking build it does look and feel premium – moreso than it does in review videos. When active the Radeon text on the side glows red, and there is also a “GPU Tachometer” which shows the load on the card. There are also hardware switches which let you recolor or disable the LEDs.

Driver, Kernel, and Installation

This is my first gripe. The AMDGPU-PRO driver installer from the AMD website hardcodes specific distribution names into the installer .sh file. In order to install the AMD driver onto KDE Neon I had to edit the file and change “ubuntu” to “neon”, as otherwise the installer will halt and state that you cannot run the install. It felt a bit wrong and I’m wondering if AMD should add in a warning and continuation option should the string check fail, such as “this us unsupported and could pooch your installation, continue anyway? (y/n)”

With the string change the installer worked without complaint, but I ran into another problem after restarting: the black screen of doom when graphics have failed to start. After researching I found it was caused because my installation of KDE Neon didn’t use the hardware enablement stack or “HWE” as offered by Ubuntu LTS. After I enabled the HWE I was able to get into an X11 session.

Once I was in an X11 session screen tearing was fairly extreme. On researching I found out I could add the “TearFree” option in “10-amdgpu-pro.conf” to solve this issue. At this point I figured I solved all the major adoption problems to get back to my previous baseline from my time on the Nvidia card, so a reboot was in order to try out a clean session.


Have you picked up that I’m not providing exact instructions on how to run AMDGPU-PRO drivers on Neon with Vega? It’s because as of the time of this writing, the experience is isn’t day-to-day usable and I won’t instruct you into a sub-par session. The drivers are still very new, and after I write this I’ll be re-installing my Nvidia drivers until I can try a Mesa session on stock kernel drivers.

Applications which make use of hardware acceleration will cause the system to stutter and hang, sometimes for a few seconds. My only conclusion given the hardware on my machine is that the PRO drivers have issues. I also find that sometimes opening applications at all will cause a momentary hang, with Kate causing a several second freeze which only fixed itself as I began reaching for the power button. These are also complete system locks at the kernel level, as I’m unable to switch to the TTY interfaces and manually restart the session or kill applications.

Game performance – as much as I “game” – is lackluster and glitchy under AMD. Remembering those reports of “Nvidia only” games on Linux I can suddenly and clearly understand why this is the case. I ran several of my neglected games from Steam and even a game like Factorio had glitches, while others like Rocket League were unplayable. Many were good, but all suffered performance issues. I think there’s an issue with loading and unloading data to the GPU, because the worst hangs seem to be during these steps. Rocket League took nearly 10 seconds to close and locked my entire system at this time. I simply gave up at this point with further game testing, being happy with none of the samples I tried.

I was unable to get Wayland working at this point. I’m sure I could have if I really wanted to, but my initial impressions with an X11 session were so lackluster that I decided anything Wayland would fix are still far outweighed by the general driver itself. For even simple desktop work there have been minor visual glitches, and I’ve caught moments of tearing several times despite being in TearFree mode.

In theory I could have used my Intel graphics to drive my displays, and there are instructions for doing this with Mesa drivers in headless mode on the AMD card. This would have let someone solve these problems, but sadly I didn’t have the outputs on my motherboard to support 2 Displayport displays and an HDMI tablet to try this.

Final Thoughts

I don’t know how much I want to ream on AMDGPU-PRO drivers or Vega at this point. While KDE Neon uses Ubuntu LTS as a base system, technically, the PRO drivers did state they weren’t compatible with my system. At the same time I know in theory they shouldn’t be having problems.

To a large degree I also expected the relatively overpowered card when used in my actual day-to-day activities to make up for any driver performance issues – I was banking on that. I don’t actually play my games so I don’t need Bioshock Infinite to run at 120fps – I need my desktop to run at 60. I either underestimated how badly the driver performs, or simply hit the wrong bugs, because for every minute of smooth operation I had with the driver there’s a hard stutter, hang, or jitter.

If you run Neon I can’t recommend a Vega card at this point, so I recommend you save your time and money until there’s an announcement stating that the generic Linux kernel can output to displays on Vega. At that point maybe even check back on my blog because I’ll be re-visiting Vega on Neon with Mesa, which from what I understand should be the experience I was expecting. Until then I’ll be putting the Nvidia card back into my machine for a stable desktop, as AMDGPU-PRO+Vega+Neon results in an unusable system at this point in time.

8 thoughts on “RX Vega + AMDGPU-PRO + KDE Neon

  1. Hey kver, Im sitting here today trying to make a decision between keeping my 1070Ti or trying out a big phat Vega 64 on my Neon rig at home.
    Your article was a while ago.. any chance you’ve retried or maybe had luck with later versions?


  2. The driver is working fine for me, but not Claymore (which is mysteriously segfaulting after mining pool detection) using six Sapphire Nitro RX 480s on Neon 5.11.2 (based on Ubuntu 18.04 Bionic Beaver). Is Neon 32-bit or 64-bit? If itโ€™s the former, then that would certainly have something to do with it.


  3. I have an RX550 and the amdgpu-pro drivers are fine to use with the rx series on the note of stability and such. People like myself would really like to know how you got it working for the Vega so we can use it with our cards.

    If you could elaborate on how you got hwe enabled for example, it would be appreciated. i ended up at the trusty black screen myself.


  4. Thanks for the article. I was wondering how the Vega on the Pro stack would do in KDE land. About as bad as I was expecting ๐Ÿ˜€

    BTW Have you looked at M-Bab AMD DC Kernel builds as they should allow the Vega to work fully using the open source Mesa drivers?
    I’ve used them just fine on Neon myself with a couple different AMD GPUs (though nothing as rocking as a Vega).

    Liked by 2 people

    1. I looked at using the Kernel builds, but in my general experience the further you stray from a “vanilla” experience the more prone things are to breakages. With kernels I just wasn’t willing to cross that bridge since we’re talking about a staging branch kernel on my daily driver machine.

      I’d love to say I’ve been proven wrong, but I recently saw a ping on some of my feeds that a recent KDE Neon update didn’t work with Padoka kernels (which were the ones I was considering) and resulted in a black screen of death. I know enough to recover from that sort of thing, but it puts me on edge. :/

      I figured instead I’d just be patient, and just today the DC code got ack’d into the 4.15 kernel. I’ll wait for a bit longer to see if Ubuntu HWE pulls in the 4.15 DC code, and if it doesn’t I’ll look into a PPA which hosts stable kernels.


      1. Padoka kernels? Didn’t know Padoka did kernels. Last i checked his repository was for vanilla Mesa. So it is upstream.

        By any chance are you referring to this bug report:
        From what I can tell is going on with the packaging, that issue will affect the normal HWE as well.

        I would have bet good money that the DC code would not be submitted for 4.15 and that you’d be waiting a while but its great to see that announcement today (I had missed it till you mentioned it here) and definitely worth holding out now as its that close.

        Note that M-Bab’s builds are vanilla upstream stable kernel releases, just with AMD’s DC patches. And with 4.9 being an LTS kernel he’s kept that updated.

        It will likely be another 6+ months before the HWE gets a version with DC based on how often they update the HWE stack (the next will be 4.13 from Artful). But the Ubuntu 4.15 kernel builds will likely appear in a couple of weeks with the RC1 release. Maybe it’ll tempt you and you can let the rest of us know how it goes ๐Ÿ™‚


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s