AMD Stages A Number Of Fixes Ahead Of Linux 4.20~5.0 - Plus Vega 20 "MGPU Fan Boost"

[Ansla]

As much as I welcome the AMD driver news, which is good almost every day, I'm certainly not the only one who finally wants out-of-the-box Adaptive Sync support. One has the feeling that we have been "nearing completion" for a year, but that nothing really goes in the direction of completion.

I really hope that DC and the necessary adjustments in user space will be ready by the middle of next year. And no, the proprietary solution is not an option for most of us.

BR

amdgpu-pro is not proprietary (at least not the OpenGL implementation), unless you explicitly request the enterprise version when installing the driver. It's just mesa + some patches that are not yet upstream. Unless you are using a source based distribution the difference between using amdgpu-pro and using the mesa your distribution provides is minor, just who build the blob that you download and run.

[xception]

Why, exactly? Unlike fglrx, I see no reason why amdgpu-pro isn't an option for most x86 users.

Well, for me it's mainly ideological reasons, but not only that, I do ocasionally try the closed drivers, mostly for comparison reasons, but it's a real pain for me to even check them since they are not packaged under gentoo, so when I want to try them I have to do a lot of work just to see how they work (and hope I end up unpacking them right, since that seems unnecessarily complicated to me, many files spread across multiple archives which are not in line with where I have to put the files in my system). I do however use the closed-source opencl stack (dev-libs/amdgpu-pro-opencl is the ebuild for it) on linux since it's the only way I can get blender to do any rendering (doesn't even compile shaders on clover) on the gpu and there's an ebuild provided by default.

Besides that I do a lot of coding and seems like every time I try them they are significantly worse at text rendering (yes, in a very noticeable manner since my IDE seems to be choking with those drivers, and the console seems to be stuttering) than the open-source drivers so even if they are in some cases better for gaming they're not an option for everyday use due to these reasons (it may be possible that I'm not doing something right here since I wouldn't consider myself an expert in figuring out what goes where, just saying from what I experienced when I got them to /*seem to*/ work)

[theriddick]

These Multi-GPU features are only going to be useful in DX12 and Vulkan IF a developer supports it (not SLI/CF), and so far I don't know of any games that even use the mGPU component of Vulkan.

Can't wait for the day when AMD releases a 1080TI beater, but since I moved to ITX case, it may limit my options even though NVIDIA top end cards come in MINI/SFF formats these days (not many AMD GPU vendors seem interesting in SFF, but then again Vega is a HOT card so perhaps not practical).

[JohnGalt]

I've been testing these changes a bit, and very happy with it overall. I'm also very glad that at least on Polaris, 4k@60hz support is back. Unfortunately it breaks hdmi audio pitch, but is a good recovery at least, especially since we had working 4k 60hz support prior to 4.18 for a bit.

Would you give me a source for a notable game that runs faster on AMD hardware under Linux?

Almost anything OpenGL will run significantly faster on linux than windows for new hardware, because the single threaded windows driver is very slow. This is why many in the emulation community recommend Linux for AMDGPU hardware when opengl is the only supported option. A great example is seen in the CEMU (wiiu) community.

Some games also run faster in DXVK (far cry 5, maybe others), though there may be other issues like stutters. DOOM vulkan also runs slightly faster for me with radv in linux at 4k than on windows.

[ryad]

You are making quite a lot of assumptions and broad generalizations here. Mind explaining why AMD has roughly 25% of the Windows marketshare? The vast majority of Windows users don't give a crap about open-source drivers, and yet, AMD still makes sales. In other words, that's quite a large percentage of people who are buying AMD for reasons that are not sharing your ideologies. So clearly, there are other reasons to buy AMD.

That is true. However, I talked about switching to AMD on Linux. I stick to claiming that a large number of AMD customers have changed over the past two years, to a great extent for non-material reasons (including myself).

Typically, Linux hardware usage tends to be pretty similar compared to Windows (when accounting for x86 systems). For example, the GTX 1060 is the most popular on both platforms. I'm sure you can extrapolate from this that there are at roughly the same amount of Linux users who buy AMD for the same incentives that they would have bought AMD when/if using Windows. Of course, there are plenty of people whose decision would be reinforced by the open-source drivers, and, there are also those who, like yourself, only bought AMD strictly because of ideological reasons. That being said, I wouldn't be surprised if the AMD marketshare on Linux is higher than it is on Windows (the Intel GPU marketshare seems to be higher too). But, I'm pretty confident that people who buy AMD strictly for ideological reasons are in the minority, because those who don't prioritize games but still want an open-source platform tend to opt for Intel.

I disagree here. First, I didn't only bought because of ideological reasons. It was part of the decision, but not the one and only argument.
You can see very nicely in the benchmarks here on Phoronix that the 1060 almost always stands out against the 580. The same benchmarks on Windows often show a different picture, respectively the cards are often equal. From this it follows that Nvidia manages to develop great drivers for Linux, while AMD's drivers are always a two-digit percentage behind the Windows drivers. Don't misunderstand, I love my 580 and certainly don't want to trade it for a 1060, even if I don't achieve the same performance. Still, it's a fact that the proprietary AMD driver doesn't exhaust the hardware. Therefore I can also use the open-source stack right away.

All that being said, yes, if you bought AMD solely because of open-source drivers, then the closed-source drivers aren't an option. But I'm willing to bet you any amount of money that regardless of OS, the majority of gamers who have a Freesync display prefer functional drivers over open source ones.

Might be true. I think pure gamers don't use Linux anyway. I only use Linux because I am most productive with it. Nevertheless, I also like to play in my spare time. That's why I need a card that can also be used for gaming. My display supports Freesync (that's why I've been waiting so long for it), but I still prefer the easy to install, wonderfully working open-source stack than the cloused-source variant. I suspect that many people see this in a similar way.

Also in many cases, the AMD Linux drivers (open source or otherwise) do actually outperform the Windows drivers. Where they don't, Nvidia's drivers don't tend to, either, due to insufficient optimizations of their porting.

Would you give me a source for a notable game that runs faster on AMD hardware under Linux?

I agree that AMD has made a bit of a mess regarding their drivers, though, I'm also inclined to believe this problem you bring up is also Debian's fault; not just AMD's.

I don't understand how you came up with Debian? I think any enthusiast who uses Debian is competent enough to set up appropriate Bleeding Edge repos. What I mentioned has nothing to do with a distribution discussion, but simply with the fact that adaptive sync is still not available in the open-source stack and performance is generally lagging behind Windows.

[shmerl]

That's a lot of fixes. I hope broken tty / *ERROR* REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank is finally fixed there.

[schmidtbag]

Well, let's be honest. I, like probably many others, switched to AMD mainly for ideological reasons. Because there are open-source drivers, we are independent of any decisions by the manufacturer and it is more sympathetic to support the underdog (for several reasons). But in terms of performance, the manufacturer doesn't really provide convincing reasons. Neither hardware nor software. To my knowledge, AMD's proprietary Linux driver is still much worse than the Windows driver. Quite contrary to nvidia's Linux driver. It just doesn't make much sense to use the proprietary amdgpu-pro when you can have the same performance with the open-source stack, except adaptive sync of course. But if I wanted to continue using closed-source drivers, I could have stayed with the competitor.

You are making quite a lot of assumptions and broad generalizations here. Mind explaining why AMD has roughly 25% of the Windows marketshare? The vast majority of Windows users don't give a crap about open-source drivers, and yet, AMD still makes sales. In other words, that's quite a large percentage of people who are buying AMD for reasons that are not sharing your ideologies. So clearly, there are other reasons to buy AMD.

Typically, Linux hardware usage tends to be pretty similar compared to Windows (when accounting for x86 systems). For example, the GTX 1060 is the most popular on both platforms. I'm sure you can extrapolate from this that there are at roughly the same amount of Linux users who buy AMD for the same incentives that they would have bought AMD when/if using Windows. Of course, there are plenty of people whose decision would be reinforced by the open-source drivers, and, there are also those who, like yourself, only bought AMD strictly because of ideological reasons. That being said, I wouldn't be surprised if the AMD marketshare on Linux is higher than it is on Windows (the Intel GPU marketshare seems to be higher too). But, I'm pretty confident that people who buy AMD strictly for ideological reasons are in the minority, because those who don't prioritize games but still want an open-source platform tend to opt for Intel.

All that being said, yes, if you bought AMD solely because of open-source drivers, then the closed-source drivers aren't an option. But I'm willing to bet you any amount of money that regardless of OS, the majority of gamers who have a Freesync display prefer functional drivers over open source ones.

Also in many cases, the AMD Linux drivers (open source or otherwise) do actually outperform the Windows drivers. Where they don't, Nvidia's drivers don't tend to, either, due to insufficient optimizations of their porting.

Instead of rolling a standard OpenCL group of packages against Debian's standard Mesa distribution you have a mess dealing with trying to make the Pro stack work. And with 18.30 they really don't allow it to work outside of those sanctioned options.

ROCm is a bag of hurt still on Debian. There is probably a reason it has yet to be actually sterilized and sanctioned with a maintainer from Debian.

I agree that AMD has made a bit of a mess regarding their drivers, though, I'm also inclined to believe this problem you bring up is also Debian's fault; not just AMD's.

[ryad]

Patches for FreeSync support in upstream kernel / xf86-video-amdgpu / Mesa are currently being reviewed, the latest revisions are pretty close to ready. There's a good chance it'll all land this year.

That would be awesome Hope, you're right!

[MrCooper]

As much as I welcome the AMD driver news, which is good almost every day, I'm certainly not the only one who finally wants out-of-the-box Adaptive Sync support. One has the feeling that we have been "nearing completion" for a year, but that nothing really goes in the direction of completion.

I really hope that DC and the necessary adjustments in user space will be ready by the middle of next year.

Patches for FreeSync support in upstream kernel / xf86-video-amdgpu / Mesa are currently being reviewed, the latest revisions are pretty close to ready. There's a good chance it'll all land this year.

[Marc Driftmeyer]

Why, exactly? Unlike fglrx, I see no reason why amdgpu-pro isn't an option for most x86 users.

Seeing as I have zero interest in RHEL, Ubuntu, SLES/SLEP or CentOS [never mind the strict versions of each] it's DOA for folks who have enjoyed and continue to enjoy Debian [you know the distribution Ubuntu draws upon for its very existence], but yeah everyone uses those others alone, right?

Instead of rolling a standard OpenCL group of packages against Debian's standard Mesa distribution you have a mess dealing with trying to make the Pro stack work. And with 18.30 they really don't allow it to work outside of those sanctioned options.

ROCm is a bag of hurt still on Debian. There is probably a reason it has yet to be actually sterilized and sanctioned with a maintainer from Debian.