Check out our Monthly Survey Page to see what our users are running.
Marek Olšák has recently sent word to the AMD mailing list that they have found a reason for some games performing poorly using Mesa. Another developer noted that a patch is already in progress.

QuoteI'm seeing random temporary freezes (up to 2 seconds) under memory
pressure. Before I describe the exact circumstances, I'd like to say
that this is a serious issue affecting playability of certain AAA
Linux games.


Marek goes on to detail how to reproduce it and suggests some workarounds.
QuoteIn order to reproduce this, an application should:
- allocate a few very large buffers (256-512 MB per buffer)
- allocate more memory than there is available VRAM. The issue also
occurs (but at a lower frequency) if the app needs only 80% of VRAM.

Example: ttm_bo_validate needs to migrate a 512 MB buffer. The total
size of moved memory for that call can be as high as 1.5 GB. This is
always followed by a big temporary drop in VRAM usage.


The good news is that another message from Christian König states they they are already working on it, and they may have something to show rather soon:
QuoteHi Marek,

I'm already working on this.

My current approach is to use a custom BO manager for VRAM with TTM and
so split allocations into chunks of 4MB.

Large BOs are still swapped out as one, but it makes it much more likely
to that you can allocate 1/2 of VRAM as one buffer.

Give me till the end of the week to finish this and then we can test if
that's sufficient or if we need to do more.

Regards,
Christian.


It's really great to see some attention to performance and not just getting their feature list up to spec. Onwards and upwards!

I've said for a long time now to heated debates that AMD drivers (both open and closed) need work on performance and that it's not purely down to game porters. It will be great if this helps certain games gain official support on AMD with Mesa in future. Article taken from GamingOnLinux.com.
0 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
42 comments
Page: «4/5»
  Go to:

Shmerl 19 Aug, 2016
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.
edddeduck_feral 19 Aug, 2016
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.
grigi 19 Aug, 2016
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 :-)
buenaventura 19 Aug, 2016
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?
edddeduck_feral 19 Aug, 2016
Quoting: grigiAs 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 :)

Quoting: buenaventuraHow 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.
Mountain Man 19 Aug, 2016
Quoting: babaiI 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.
nattydread 19 Aug, 2016
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.
bridgman 20 Aug, 2016
Quoting: AnxiousInfusion*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
davidjosepha 20 Aug, 2016
Quoting: BdMdesigN
Quoting: liamdaweYou 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.
throgh 22 Aug, 2016
Quoting: babaiI 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.
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!