A reason for poor performance on AMD plus Mesa has been found and a patch is in progress

I'm very excited preparing to switch to Red Camp, I'll be TTY switching like it's 1999, and kiss goodbye to GPU buffer corruption from NVidia.

Yes, yes you will my friend :)

I won't go into details but I've just switched from a 660GTX to a RX480 (as mentioned) on my workstation.

Result: I've been running the RX480 (Mesa) for a week and, so far, you couldn't pay me enough to make me switch back - which is a massive statement on how far AMD have come.

You should remember not everyone uses Linux for just freedom, there's many reasons. You should just accept others choices and move on. Not everyone needs a lecture and we don't need an AMD topic derailed because of it :)

^ This. If anyone don't accept thats i buy NVIDIA is a Nazi. The freedom is the choice in Software and Hardware and if a Hardware have poor drivers i don't buy the Hardware, thats MY choice.

But if you tell people what Hardware they should buy is a dictation and has nothing to do with freedom.

I Agree that customers should expect proper performance right now and not wait for another year, also this fix will probably go into the radeonSI userspace driver and not MESA.
Still, AMD has contributed much code to MESA in the past years, show me some from NVIDIA (no please not any Tegra DRM code)?
If you are using Linux for freedom/open source idealism, ideologically you SHOULD buy AMD products and not tell me how a 1060 overpowers an RX480 today. AMD had no obligations towards supporting MESA or opening up millions of lines of DPM code for their chips. They still did.
Support a company that supports your platform.
If you don't follow the open source philosophy and using Linux just because you like say the millions of widget themes it supports or for any other reason, buy Nvidia.

*Cautiously points out that AMD GPUs require closed firmware blobs.

Good news, improvements for AMD drivers are always good.

My fellow Linux Peeps, we are a community who most of us likely has control issues, when Linus couldn't control the quality of the nVidia driver or force them into using a FOSS driver he gave them the finger.

Whatever floats your boat, but, he was really giving the finger to Optimus support (or lack there of), and their Android support. He did go back and give them a thumbs up, though, especially around their open source efforts on the Tegra K1 chips and integrating it into Nouveau.

Good. RX 480 seem to be always out of stock. By this rate, I'd probably wait for Vega cards already.

Good. RX 480 seem to be always out of stock. By this rate, I'd probably wait for Vega cards already.

This is where i'm at with it, I had no idea the product would be so slammed with buyers since it seems like the bitcoin miners have passed to custom hardware.

You good sir do you happen to know what time frame Vega is coming?

I just had 2 system builds for Linux users this week and unfortunately Zen hasn't dropped yet so I had to select a Intel combo instead of AMD APU :\.

Some speculate, Vega can come early, already this October. Others say it can come sometime in the beginning of next year. I have no idea really if that is correct or not.

This issue is all about memory management of the cards memory, this will usually be seen in games as a dramatic slowdown or stall that will suddenly happen at some point only for the game to (usually) recover again some seconds later.

These are caused by VRAM pressure. Most complex games over the course of playing allocate more memory than the card has VRAM. As a result, the memory manager constantly migrates buffers between VRAM and RAM depending on which buffers are
used at the given time. Eventually VRAM becomes fragmented, so the memory manager decides to evict a lot of less important buffers out of VRAM to make space, when this happens you'll experience a stall in gameplay. The size of the stall depends on the size of the buffers involved.

The improvement being discussed the last time I read the thread was to split the memory on the card into smaller chunks reducing the chance fragmentation will require a flush of buffers to fit larger buffers in memory.

Bottom line this is unlikely to boost your base frame rate but it could make noticeable improvements to games where you get stutters and stalls as these could be being caused by memory fragmentation on the card.

However it won't fix all instances in all games as stalls in rendering can be caused by many different things and this is just one possibility.

As a Laptop user stuck with 1G of VRAM on a still-relatively-beefy 7770M, I do notice stutters even with compositing when I have a 2'nd external 4K monitor and tens of apps open in virtual screens. it will be smooth, then stall for 1/4s even.
Exciting times to be an open-source AMD user :-)

How nice, it's great that they are working on this. When could one expect to see it in the driver in the ubuntu repositories? Does it take a long time?

As a Laptop user stuck with 1G of VRAM on a still-relatively-beefy 7770M, I do notice stutters even with compositing when I have a 2'nd external 4K monitor and tens of apps open in virtual screens. it will be smooth, then stall for 1/4s even.
Exciting times to be an open-source AMD user :-)

Usually the rules are make it work correctly then make it work quickly. It's nice to see Mesa has more time for the second option as more and more of the first part has been completed :)

How nice, it's great that they are working on this. When could one expect to see it in the driver in the ubuntu repositories? Does it take a long time?

This will take quite a while to make it into the official Ubuntu repositories, possibly 17.04 however it will be in a PPA (like the padoka one) a lot sooner once the change has been committed and approved.

Last I checked nothing has been committed yet so it's more like they know the issue and they have a fix in progress but it still needs to be completed, checked in, approved and merged into the trunk, built into the drivers (at this stage you can check it out in padoka) then included in a stable release and finally have that stable release included in the official Ubuntu repository that you can see inside software updater.

I Agree that customers should expect proper performance right now and not wait for another year, also this fix will probably go into the radeonSI userspace driver and not MESA.
Still, AMD has contributed much code to MESA in the past years, show me some from NVIDIA (no please not any Tegra DRM code)?
If you are using Linux for freedom/open source idealism, ideologically you SHOULD buy AMD products and not tell me how a 1060 overpowers an RX480 today. AMD had no obligations towards supporting MESA or opening up millions of lines of DPM code for their chips. They still did.
Support a company that supports your platform.
If you don't follow the open source philosophy and using Linux just because you like say the millions of widget themes it supports or for any other reason, buy Nvidia.

I go with what works. Linux works for me. Windows doesn't. Nvidia works for me. AMD doesn't. It's as simple as that.

I've been burnt by spending serious money on AMD cards before only to find they are not properly supported. Both on windows and on linux. I'll stick with NVidia thanks. It doesn't mean I don't like or support open source software.

*Cautiously points out that AMD GPUs require closed firmware blobs.

Just to clarify... AMD GPUs (like all modern GPUs) use closed microcode as part of the GPU hardware design. Calling it "firmware" sometimes makes people think the code runs on the CPU, which it does not.

Some chip vendors deliver microcode in ROMs on the chip, but most these days soft-load the microcode images into RAM at power up (even Intel is soft-loading microcode in recent GPUs). This can be done by VBIOS or by drivers; we do it in the drivers so you don't have to reflash your BIOS if a microcode update is required.

So it's not incorrect to say "AMD GPUs require closed firmware blobs" but it would be more correct to say "all modern GPUs require closed firmware blobs".


Last edited by bridgman on 20 August 2016 at 2:47 am UTC

You should remember not everyone uses Linux for just freedom, there's many reasons. You should just accept others choices and move on. Not everyone needs a lecture and we don't need an AMD topic derailed because of it :)

^ This. If anyone don't accept thats i buy NVIDIA is a Nazi. The freedom is the choice in Software and Hardware and if a Hardware have poor drivers i don't buy the Hardware, thats MY choice.

You say "^ This" but apparently missed the point, since you continue the derailment of the thread (which I will continue...). You are, however, incorrect in your claim about the freedom of linux. In fact, the GPL, under which the kernel and all of the GNU userland is released, is precisely AGAINST this freedom. It and similar copyleft licenses are aimed at removing anything close sourced from existence. The idea isn't freedom of choice, but freedom FROM closed source software. This might not be something you agree with, but don't misunderstand the "freedom of linux".

AMD aren't perfect (closed firmware blobs), but they're miles ahead of nvidia in terms of supporting your freedom.

This is absolutely great news, though. I've been using AMD's free drivers since 2012, and they just keep getting better. Even then, they weren't buggy, they were just slow. I've found catalyst, nouveau, and nvidia's proprietary driver to all be buggier than radeon, although, I'll admit, nvidia's proprietary has better performance. Still, the "if you game on linux, use nvidia" line is becoming even less correct than it was 4 years ago. I'm gaming just fine with radeon in 1440p. Hopefully this patch works towards making an even better free driver for those of us who don't want to support nvidia's crooked business tactics and want to support the company that's supporting us, even at a 10-20% performance loss.

I Agree that customers should expect proper performance right now and not wait for another year, also this fix will probably go into the radeonSI userspace driver and not MESA.
Still, AMD has contributed much code to MESA in the past years, show me some from NVIDIA (no please not any Tegra DRM code)?
If you are using Linux for freedom/open source idealism, ideologically you SHOULD buy AMD products and not tell me how a 1060 overpowers an RX480 today. AMD had no obligations towards supporting MESA or opening up millions of lines of DPM code for their chips. They still did.
Support a company that supports your platform.
If you don't follow the open source philosophy and using Linux just because you like say the millions of widget themes it supports or for any other reason, buy Nvidia.

No neither AMD nor NVidia means really freedom and even the implementation within Mesa have to use a firmware-file (blobs), which is not open, free or libre at all. Everything else around? Okay, but the firmware-image has to be used. Therefore also the libre kernel cannot allocate newer cards for the blobs are removed - better to say their allocation is completely removed and even if they are existent nothing happens. And turns out being much work deblobbing the driver! So this is not free or libre.

I recently moved from a 390x to a 980Ti, not regretting it. To be honest the AMD card was fine under Windows minus some weird Vulkan driver BSOD issues, but under Linux most my games didn't launch or had major performance/graphics issues.

I'm sure within a couple years AMD will figure this whole Linux driver thing out, I just didn't want to wait around for that to happen, if you are comfortable with waiting then that's fine.

PS. I also game at 4k, so, yeah.