81 Fresh Patches For AMDGPU's DC (DAL) Display Code

[bridgman]

I think there is a freesync_capable value which probably has useful info:

http://support.amd.com/en-us/kb-articles/Pages/HOW-TO-ENABLE-AMD-FREESYNC-IN-LINUX.aspx

[gurv]

I haven't heard anything about Freesync being broken on AMDGPU-PRO but I could have missed something. Which GPU are you using ?

freesync currently only works with the pro stack ddx. For upstream, we need to design a vendor neutral interface rather than the current AMD specific interface. We are working on getting the current freesync code working on the all-open stack for testing purposes as a test bed for designing something for upstream.

Sorry to reply so late, I wanted to do some additional testing.

I'm using an MSI RX 470 on Linux Mint 18.1 with the following driver configurations :
- AMDGPU-PRO 17.10 + stock kernel 4.8
- amd-staging 4.11 (compiled by myself) + manually patched amdgpu_drv.so
- amd-staging 4.11 (compiled by myself) + AMDGPU-Pro 17.10's amdgpu_drv.so

I don't know if it matters but DRI3 is forced on in xorg.conf and cinnamon is set to unredirect fullscreen windows.
(though IIRC I've tried toying with these settings to no avail)

Neither of the above configurations seems to work.
Granted it's not always easy to tell if Freesync is enabled: I had to do a temp install of Windows 7 + freesync windmill demo to see what it should look like.

So in order to more easily test it, I've written a very simple fullscreen glut program that draws a vertical white rectangle scrolling from left to right at 45fps (like windmill demo in test pattern mode).
And it obviously stutters with vsync@60Hz even when freesync is supposed to be enabled (xrandr --output DisplayPort-1 --set "freesync" "1") with the open stack (amd staging 4.11 and either self patched amdgpu_drv.so or amdgpu-pro's one).
Unfortunately, I haven't been able to test my program with AMDGPU-Pro as it segfaults in libGL.so ...

I've tried investigating why freesync wasn't switched on and I discovered that info->fullscreen_client was always null in amdgpu_present.c even when the application (my program or unigine valley) was obviously in fullscreen.

That's where I got stuck and now I'm at my wits' end

[duby229]

It's not correct to say Vega is the first who needs it.
All generations supported by amdgpu need it for FreeSync, atomic modesetting and audio over HDMI/DP. Vega just needs it more as it can't even display anyhting on the screen without it.

Which, ironically enough is a circumstance that adequately resembles the first two of the three E's. I'm not saying that's intentionally what it is, I doubt it in fact, but regardless I'd bet the end result will be be the third E even if it wasn't intentional. AMD is seriously underestimating open source enthusiasts if they think they can get them to use out of tree components.

[Ansla]

I would name it by the first hardware who needs this code and the main function the people want from this code.

this means AMD VEGA founders edition is the first hardware who needs it and the people want to play HDMI Audio over it.

why not name it VHA (vega hdmi audio)

It's not correct to say Vega is the first who needs it.
All generations supported by amdgpu need it for FreeSync, atomic modesetting and audio over HDMI/DP. Vega just needs it more as it can't even display anyhting on the screen without it.

[bridgman]

bridgman : is it the case for AMDGPU-PRO too? I installed the latest version (17.10) and couldn't make Freesync work either.

I haven't heard anything about Freesync being broken on AMDGPU-PRO but I could have missed something. Which GPU are you using ?

[agd5f]

So that's why I couldn't get Freesync to work on my brand new monitor with AMD's 4.11 staging tree : it's currently broken
At least, I won't have to continue scratching my head

bridgman : is it the case for AMDGPU-PRO too? I installed the latest version (17.10) and couldn't make Freesync work either.

freesync currently only works with the pro stack ddx. For upstream, we need to design a vendor neutral interface rather than the current AMD specific interface. We are working on getting the current freesync code working on the all-open stack for testing purposes as a test bed for designing something for upstream.

[gurv]

So that's why I couldn't get Freesync to work on my brand new monitor with AMD's 4.11 staging tree : it's currently broken
At least, I won't have to continue scratching my head

bridgman : is it the case for AMDGPU-PRO too? I installed the latest version (17.10) and couldn't make Freesync work either.

[bridgman]

That's different from the convention we use everywhere else, which is "first HW supported by the code" (CI I guess).

We could call it "Display code for Ci and up", or DC for short

[bridgman]

I'm not saying to leave them out - I'm aware of their significance. I just think it's funny for Michael to report on them, since the average reader here isn't affected by them. Hence the tire analogy.

Ahh, OK. Yeah, that occurred to me after I posted, but I had already closed the thread and didn't have time to go back and try to re-find it. Makes sense.

[bridgman]

I 'm wondering, there is a KMS interface in the kernel, which basically all modern GPU's use for modesetting. Why don't the linux kernel devs just develop a display interface which all GPU's can use for display interfaces? Or am I just misunderstanding badly?

There is... but it's a moving target because it is constantly evolving. We just happened to be implementing new code against it while it was going through a very high rate of change, maybe the greatest since the introduction of KMS. It's that whole "stable API" discussion again... a rapidly evolving interface makes it easier to stay current with new hardware in principle but in practice raises the bar pretty high when trying to write & upstream new code against it.