Language Selection

English French German Italian Portuguese Spanish

AMD Radeon VII Linux Performance vs. NVIDIA Gaming On Ubuntu For Q2'2019

Filed under
Graphics/Benchmarks
Gaming

It's been three months now since the AMD Radeon VII 7nm "Vega 20" graphics card was released and while we hopefully won't be waiting much longer for Navi to make its debut, for the time being this is the latest and great AMD Radeon consumer graphics card -- priced at around $700 USD. Here are some fresh benchmarks of the Radeon VII on Linux and compared to various high-end NVIDIA graphics cards while all testing happened from Ubuntu 19.04.

Fortunately, the open-source Radeon VII Linux support is in fact in great shape. There was some confusion for some weeks and a lack of benchmarks recently since I had been unable to get my Vega 20 graphics card running reliably. Under different OpenGL/Vulkan workloads and even some desktop tasks, the graphics card would freeze and spewing from dmesg would most often be a load of VMC page faults and other errors stemming from AMDGPU. But after a lot of testing, ultimately it was figured out the graphics card became defective in some manner. The original card was a pre-launch Radeon VII review sample and was my lone Vega 20 GPU but has now been fortunately replaced by AMD. I received a new Radeon VII last week and since then has been under near constant load/testing. This new card has been working out well and I haven't encountered any issues with this retail card, unlike the woes I experienced with the original VII a few weeks after launch. It was a bit surprising the original Radeon VII failed especially without having done any over-clocking to it (granted was pushed very hard for a few weeks with all of my benchmarking workloads), but whatever the case, this retail Radeon VII is working out fine on Ubuntu 19.04 and various kernel/Mesa upgrades.

Read more

More in Tux Machines

today's howtos

Android Leftovers

Latest From Libinput

  • libinput and tablet proximity handling
    This is merely an update on the current status quo, if you read this post in a year's time some of the details may have changed libinput provides an API to handle graphics tablets, i.e. the tablets that are used by artists. The interface is based around tools, each of which can be in proximity at any time. "Proximity" simply means "in detectable range". libinput promises that any interaction is framed by a proximity in and proximity out event pair, but getting to this turned out to be complicated. libinput has seen a few changes recently here, so let's dig into those. Remember that proverb about seeing what goes into a sausage? Yeah, that.
  • libinput and the Dell Canvas Totem
    We're on the road to he^libinput 1.14 and last week I merged the Dell Canvas Totem support. "Wait, what?" I hear you ask, and "What is that?". Good question - but do pay attention to random press releases more. The Totem (Dell.com) is a round knob that can be placed on the Dell Canvas. Which itself is a pen and touch device, not unlike the Wacom Cintiq range if you're familiar with those (if not, there's always lmgtfy).
  • Libinput 1.14 Will Support Dell's Totem Input Device
    Dell announced the Totem two years ago while the Linux support is finally getting in order. However, there isn't yet any notable applications/tool-kits at least on Linux that support utilizing this specialized input device. Red Hat input expert Peter Hutterer, who also maintains libinput, has blogged about the Totem support addition for the upcoming libinput 1.14. If you are interested in this unique input device, Peter's post has all the interesting technical bits.

Jami/Ring, finally functioning peer to peer communication client

Some years ago, in 2016, I wrote for the first time about the Ring peer to peer messaging system. It would provide messaging without any central server coordinating the system and without requiring all users to register a phone number or own a mobile phone. Back then, I could not get it to work, and put it aside until it had seen more development. A few days ago I decided to give it another try, and am happy to report that this time I am able to not only send and receive messages, but also place audio and video calls. But only if UDP is not blocked into your network. The Ring system changed name earlier this year to Jami. I tried doing web search for 'ring' when I discovered it for the first time, and can only applaud this change as it is impossible to find something called Ring among the noise of other uses of that word. Now you can search for 'jami' and this client and the Jami system is the first hit at least on duckduckgo. Jami will by default encrypt messages as well as audio and video calls, and try to send them directly between the communicating parties if possible. If this proves impossible (for example if both ends are behind NAT), it will use a central SIP TURN server maintained by the Jami project. Jami can also be a normal SIP client. If the SIP server is unencrypted, the audio and video calls will also be unencrypted. This is as far as I know the only case where Jami will do anything without encryption. Read more