AMDGPU DC Code Improvements Bring Better Page-Flipping

[MrCooper]

Mesa does have that functionality since 2013 (https://phoronix.com/scan.php?page=news_item&px=MTU0NDE), [...]

That never landed (unfortunately, Michael tends to report on patches which were merely submitted for review as if they were already landing). Even if Mesa starts supporting this in the future (should be pretty easy to implement with DRI3/Present), it'll be disabled by default, unless enabled by the application via the GLX_EXT_swap_control_tear extension (or by the user via driconf).

Is this about a particular application? It sounds like it doesn't measure frame times properly, causing it to use wildly varying animation steps between frames. If you have a test case demonstrating a Mesa bug, please file a bug report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa .

[L_A_G]

...

As I said, when you're using hardware that isn't officially supported you really don't have all that much to legitimately complain about. It's a bit like complaining that an american car from before they took lead-based additives out of gasoline doesn't run all that well on un-leaded and that said manufacturer's cars don't run that well because of it.

Talking about support under windows is also pretty pointless as the Windows driver simply hasn't gone trough anything like the re-write that the Linux driver went trough with the move to AMDGPU. On linux said hardware is older than the main codebase, meaning proper support requires a whole bunch of legacy code paths to be written, which is drastically different to the Windows driver where the main codebase is older than the hardware and the necessary code paths were added the hardware was new.

[Azpegath]

L_A_G - Yeah, that's a crappy situation.

My R9 390 has Direct 3D 12, Vulkan 1.1 and Open GL 4.x, Open CL 2.x, Freesync over HDMI, H.264 and H.265 decoding and encoding, Wattman supported in Windows.

In Linux by comparison, the officially supported Radeon kernel driver excludes Vulkan, Freesync support. Only with the "experimental" support in AMDGPU kernel driver do we get Vulkan and Freesync support. The AMDGPU driver is more stable and performant for my R9 390, than the radeon kernel driver - it's the reason I switched in the first place. At most OpenCL 1.1 is supported, and I think it's half baked support not full support. H.264 decoding and encoding seems to be supported. The driver quality sucks, there's always some new bug in each new kernel version (and in point releases as well). Either the GPU hangs randomly, or the screen stops working after suspend and resume.

As far as I can see, AMD's Linux support is mediocre - way better than NVIDIA's closed source crap and their Wayland situation, but AMD's support is pretty bad in comparison to Intel's Linux drivers.

I'm a bit surprised at that as well... I would think that AMD would have a huge test farm, with at least one of every card, running nightly builds of every kernel branch, running at least the mesa regression test suite, including power cycle tests. It's not like the cards are expensive for them.

L_A_G - Yeah, that's a crappy situation.

My R9 390 has Direct 3D 12, Vulkan 1.1 and Open GL 4.x, Open CL 2.x, Freesync over HDMI, H.264 and H.265 decoding and encoding, Wattman supported in Windows.

In Linux by comparison, the officially supported Radeon kernel driver excludes Vulkan, Freesync support. Only with the "experimental" support in AMDGPU kernel driver do we get Vulkan and Freesync support. The AMDGPU driver is more stable and performant for my R9 390, than the radeon kernel driver - it's the reason I switched in the first place. At most OpenCL 1.1 is supported, and I think it's half baked support not full support. H.264 decoding and encoding seems to be supported. The driver quality sucks, there's always some new bug in each new kernel version (and in point releases as well). Either the GPU hangs randomly, or the screen stops working after suspend and resume.

As far as I can see, AMD's Linux support is mediocre - way better than NVIDIA's closed source crap and their Wayland situation, but AMD's support is pretty bad in comparison to Intel's Linux drivers.

[Azpegath]

Since 4.19, everything is running perfectly for me with the RX 560.
Whether it is switching output screen, turning AV receiver off/on (used for playing sound and passing through image via HDMI to output screen) , switching monitor on/off, or the more touchy suspending/resuming. All the bits that were initially leading to freezes have been ironed out starting with 4.19.

I am currently at 90 days of uptime with 100+ suspending/resuming and AV Receiver turning off/on, gaming, Spotifying, netflixing and many other stuff included. amdgpu is now completely stable for me.

Interesting, 4.19 doesn't boot at all with Hawaii cards, until (I think) 4.19.15 or so, because of incorrect recognition of the cards caused by a bug. Michael wrote an article about it after I sent him a link to the bug report. This also resulted in the bug-fix being merged almost immediately after the article came out. But like I said, I haven't had the guts to try the kernels after the fix.

[salsadoom]

What is this? *Finally* freesync over hdmi?? Awesome!

Shit, I just realized I misread the blurb. Well, shit. Looks like HDMI users get left out in the cold again. Why is this such a damn problem, it works just fine in Windows for F sakes.

[tildearrow]

Sorry need some coffee I think this reddit page has some links and info for what your looking for. https://www.reddit.com/r/linuxquesti..._mode_setting/

Neither option fixed the issue.

By the way, here is an animation of the issue:

[You-]

Anyone with DC problems, too? Since DC is merged, I only get black screen (on my 4k screen) during boot. I can disable DC, and then command line works. But well...

I have a similar issue with an ultrawidescreen monitor giving me a blank screen (though the non-DC code paths also had issues of not correctly displaying antice resolution).

I have it reported here: https://bugs.freedesktop.org/show_bug.cgi?id=107668 - I tried 5.0 RC1 but that hadnt got the fix in yet.

[Mez']

It's a shame it doesn't get into 5.0, it would be nice to have some clean-ups of the DC as soon as possible. I agree with oleid, there has been many stability issues with DC. I'm running it on a R290, so I guess I'm an outlier (they aren't officially supported, right?) and have to accept some issues, but the kernel didn't even boot for 2 whole main release versions. Now they've fixed the first specific issue I had, but I still haven't tried updating to anything newer than 4.18.20, since there where so many other issues (the filesystem corruption, etc). I think I'm mainly waiting for 5.0.(>5), to not risk hitting any issues.

Since 4.19, everything is running perfectly for me with the RX 560.
Whether it is switching output screen, turning AV receiver off/on (used for playing sound and passing through image via HDMI to output screen) , switching monitor on/off, or the more touchy suspending/resuming. All the bits that were initially leading to freezes have been ironed out starting with 4.19.

I am currently at 90 days of uptime with 100+ suspending/resuming and AV Receiver turning off/on, gaming, Spotifying, netflixing and many other stuff included. amdgpu is now completely stable for me.

[DarkFoss]

Note that I do not mean Adaptive-Sync (AKA FreeSync), but rather Adaptive-VSync.

Sorry need some coffee I think this reddit page has some links and info for what your looking for. https://www.reddit.com/r/linuxquesti..._mode_setting/