Support us on Patreon
PayPal
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.
Marek goes on to detail how to reproduce it and suggests some workarounds.
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:
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.
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
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
buenaventura Aug 19, 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?
0 Likes
edddeduck_feral Aug 19, 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.
2 Likes, Who?
Mountain Man Aug 19, 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.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.
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.
5 Likes, Who?
nattydread Aug 19, 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.
0 Likes
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
2 Likes, Who?
Quoting: BdMdesigNQuoting: 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.
0 Likes
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.
0 Likes
TheRiddick Aug 25, 2016
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.
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.
0 Likes
See more from me