AMD Sends Out Patches For New AMDGPU DAL Display Driver, Adds 93k Lines Of Code

[microcode]

What you say is technically true, but with high refresh rate monitors you can achieve similar results as with adaptive sync (at least in theory). Think of what would happen if you had a monitor with an infinitely high refresh rate. Once the gpu is done with rendering a frame, it would show up immediately, with no delay. Then this rendered image would be refreshed many times (which the user doesn't recognise) until the next frame is done, which then would be displayed without a delay again. So the user's impression would be the very same as with Freesync.

Of course this theory doesn't quite fit in practice, because the fastest refreshing displays are about 144 Hz. Also, high rate refreshing has the disadvantage that you need more bandwidth for the video memory and display cable - and as a consequence more electric power However, I can understand that some people prefer a display with high refresh rate which works with all gpu vendors and is additionally a bit cheaper than adaptive sync monitors. They at least have a kind of similar effect.

Frame skips still look awful even at 120Hz or even higher. One of the two reasons for variable refresh rate monitors is to avoid full frame skips (i.e. a situation where you have been seeing 120 frames every second, and suddenly lose one and display the same frame for two refreshes). This looks awful on any monitor, including (albeit, somewhat less so,) ones operating at very high refresh rates.

Another good reason is for compositing videos in the desktop. Let's say you have a 23.976Hz video, and the native refresh rate of your monitor is 60Hz. You will either blend frames, skip frames, mistime frames, or distort the audio; all of these things are either computationally expensive, or don't look good, or both.

It would be infinitely simpler and better to just refresh at 23.976Hz while the video is the only motion, and refresh on a multiple of that rate (47.952Hz or 71.928Hz) when you want smoother motion elsewhere on the desktop (i.e. loading indicator).

[Min1123]

The patches are available at https://cgit.freedesktop.org/~agd5f/...xt-4.6-wip-dal for easier reading (and testing). These patches just hit the dri-devel mailing list but you can feel free to run this and let me know what you find.

Sorry, I can't figure out how to turn a personal repo into an anongit repo to clone anonymously. I think I may just have to wait until it gets pulled by something I have access to.

[entropy]

Almost 100k LoC... Holy cow.
Who is going to review that thoroughly?

I can't imagine that Linus likes to add such large patch sets.

[boffo]

It's over 9000 LoC!!!

[kenjitamura]

It's over 8000* LoC!!!

Fixed that for you.

[orome]

Sorry, I can't figure out how to turn a personal repo into an anongit repo to clone anonymously. I think I may just have to wait until it gets pulled by something I have access to.

click on the summary tab and the clone links are at the bottom...

[Nille_kungen]

It will take time to get this merged and i think the review will be harsh.
It wouldn't surprise me if it needs a lot of rework to get merged.

[Septor]

Presumably this will eventually replace at least 15kLoC of existing code from amdgpu... Should be able to shrink it down some more.

[humbug]

Seeing how unpopular both G-sync and Freesync are even on Windows, I wouldn't keep my hopes up. It seems to me more people prefer 120Hz+ monitors instead, since they effectively yield the same results while not being restricted by hardware.
I'm sure Freesync will come some day, but I'm sure AMD sees it as a low priority for Linux (possibly lower than Crossfire, I'm not sure).

Crossfire is something that will require game specific profiles. That would be very high maintenance on Linux at least until Vulkan games allow game devs to do it themselves. Even on windows Nvidia and AMD have problems keeping up with SLI and crossfire profiles as new games come out, and that's with significantly more manpower. On the other hand freesync is something that once implemented requires less upkeep.

[Kano]

From what we learnt from nouveau the HDMI 2.0 support seems to be active for Fuji, Tonga too, as most likely definined by stream->max_hdmi_pixel_clock = 600000;