Announcement

Collapse
No announcement yet.

Linux 4.17 To Enable AMDGPU DC By Default For All Supported GPUs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • bridgman
    replied
    Originally posted by ermo View Post
    Is it reasonable to expect the DC code-base to grow support for GCN 1.0 during 2018?

    Or are there issues (hardware bugs) that make this a non-starter?
    I don't think there are any blocking HW problems other than the SI display HW being quite a bit older than the CI display HW. The bigger difference AFAIK is simply that the existing SI display code already covers most of what the HW can do, while for CI and later the non-DC code did not include support for new-with-CI display features like adaptive sync.

    I'm not sure offhand what moving SI from current display code to DC would add.
    Last edited by bridgman; 17 March 2018, 06:40 PM.

    Leave a comment:


  • Brisse
    replied
    Originally posted by pete910 View Post

    Not sure how to see if it works then, other than how if feels whilst on/off. LFC would be a nice addition I agree.

    I had it in my head that borderless fullscreen would not work in windows too, that could have been a previous limitation or even a g-sync one though but like I siad, not used it much in windows.
    It was a bit crappy on Windows at release as well. I was an early adopter and remember those days well. It caused flickering brightness in some applications, and there was no support for borderless fullscreen or LFC. These things were fixed or added later and it works pretty well now.

    I think if you had used it a lot on Windows and gotten used to it then you would notice it's not working on Linux. I sure did when I moved away from Windows but I had already used Freesync for quite a while then. Someone who hasn't experienced it much wouldn't notice though.

    It's easy for me to see if it's working or not because the refresh rate reported in the monitor OSD constantly changes when Freesync is working. Sadly, not a lot of monitors have this feature which makes it hard to verify. Like I said, I can get xrandr and all that to say "Freesync enabled" too, but the refresh rate when I'm on Linux stays at a constant 120hz no matter what and if I look closely I will see potential stuttering with v-sync or tearing without, so despite Freesync saying it's enabled, it really is not.

    Edit: With all that said, it is not worth running Windows just for proper Freesync support, but I sure am looking forward to the day it works properly on Linux.

    Leave a comment:


  • pete910
    replied
    Originally posted by Brisse View Post

    Monitor reporting Freesync as "On" is not enough as it doesn't really tell us anything. You need to verify that the refresh rate of the monitor actually follows the frame rate of the application. I can get my monitor and xrandr to report Freesync as "On" as well, but it's not actually working at all on Linux and behaves exactly as an old fashioned fixed refresh rate monitor because the user-space in GNU/Linux isn't aware of or even compatible with adaptive refresh rates.

    When I say it works better on Windows, I mean it works in any 3d application regardless of graphics API, borderless fullscreen or exclusive fullscreen. There's low frame-rate compensation. Freesync can be always enabled and transitions from desktop to 3d applications are seamless. It just works and the user doesn't really have to do any configuration. None of these are true for AMDGPU-PRO where it requires to be manually enabled every time you launch an application and then manually disabled when you return to desktop. It only works for a handful of applications and only with specific frame buffer settings. It's basically a useless experimental feature which normal users won't even know about, much less actually use.

    One might as well say there's still no Freesync support on Linux. Technically there is with AMDGPU-PRO, but it's not useful for reasons stated above, so we might as well say there's no proper Freesync support.
    Not sure how to see if it works then, other than how if feels whilst on/off. LFC would be a nice addition I agree.

    I had it in my head that borderless fullscreen would not work in windows too, that could have been a previous limitation or even a g-sync one though but like I siad, not used it much in windows.

    Leave a comment:


  • Mez'
    replied
    Originally posted by Marc Driftmeyer View Post
    GRUB_CMDLINE_LINUX_DEFAULT="quiet iommu=pt iommu=1 amdgpu.dc=1 amdgpu.audio=1"
    I don't think amdgpu.audio=1 is necessary.
    amdgpu.dc=1 should be enough to get hdmi audio (surround) with dc. It is for me at least.

    Leave a comment:


  • Brisse
    replied
    Originally posted by pete910 View Post

    My monitor also reports is active too when enabled. It works in game too if you have the framerate caped to the monitors refresh/freesync rate



    What do you mean by limited to windows, Used on both all though not much on windows if am honest ?

    Just thought am on AMD staging ! guess there,s still a fair difference between that and what's in mainline branch!
    Monitor reporting Freesync as "On" is not enough as it doesn't really tell us anything. You need to verify that the refresh rate of the monitor actually follows the frame rate of the application. I can get my monitor and xrandr to report Freesync as "On" as well, but it's not actually working at all on Linux and behaves exactly as an old fashioned fixed refresh rate monitor because the user-space in GNU/Linux isn't aware of or even compatible with adaptive refresh rates.

    When I say it works better on Windows, I mean it works in any 3d application regardless of graphics API, borderless fullscreen or exclusive fullscreen. There's low frame-rate compensation. Freesync can be always enabled and transitions from desktop to 3d applications are seamless. It just works and the user doesn't really have to do any configuration. None of these are true for AMDGPU-PRO where it requires to be manually enabled every time you launch an application and then manually disabled when you return to desktop. It only works for a handful of applications and only with specific frame buffer settings. It's basically a useless experimental feature which normal users won't even know about, much less actually use.

    One might as well say there's still no Freesync support on Linux. Technically there is with AMDGPU-PRO, but it's not useful for reasons stated above, so we might as well say there's no proper Freesync support.

    Leave a comment:


  • duby229
    replied
    Originally posted by zzarko View Post
    OK, I have been reading driver stuff for a long time, and I'm still not sure what is the recommended option for Radeon 7950 (Tahiti, GCN 1.0) nowdays. I'm still on Ubuntu 14 64bit just for fglrx and its game support. I play a lot of Steam/GOG Linux games, even the more recent ones play just fine on HD resolution (at least for me). My setup is also very stable, I don't turn off my computer for weeks (but it goes to sleep mode when I'm not using it).

    If I'm to install a newer distribution with new kernel, which driver should I use (again: gaming is a must! ), so that I don't lose support for the games that simply just work in my current setup? Or should I stay with older kernel/xorg and fglrx?
    For your setup a newer distro would default to using the radeon kernel driver, but you could just as well use amdgpu and get vulkan and all the newest bits. You'd probably want to learn how to use an appropriate PPA in order to get the latest pieces in timely order. Once at that stage you can start playing with gallium nine or even vk9. It opens up whole new capabilities. Plus your desktop performance is going to be noticeably better even if you didn't think it was bad before. The amdgpu or the modesetting DDX driver can be used so Tear free options for xorg will actually work. And I think this one is the most important, radeonsi performs consistently equal to or better than fglrx in raw FPS while at the same time using much less CPU to do it. And that while being a much more accurate OpenGL implementation.

    Leave a comment:


  • wizard69
    replied
    First let me say that the reason i have an HPX360 with an AMD chip is the confidence i got from seeing the vastly improved Linux support and interaction from AMD. I really believe this bleeding edge hardware will be suitable for primary Linux use in a few months.

    Right now im testing Ubuntu from a USB stick and must say im impressed even if there are still significant issues. One big one is an apparent inability to resume from low power mode. In other words closing the lid and then reopening it some time latter leads to a crash.

    Originally posted by dwagner View Post
    The efforts are laudable and for gaming or HTPC use, amdgpu is certainly useable by now.
    Interestingly i have little interest in gaming but may do a HTPC at sometime in the future. What drew me to this laptop though was the GPU and CPUs which in combo represents a very powerful platform. The fact that AMD has demonstrated a commitment to GPU drivers in linux sealed the deal so to speak.

    Are the drivers perfect - certainly not however they are better than anything before and get better literally weekly. I don't expect instant perfection, i just want to see a commitment to things getting better over time.
    But for any use case where uptimes longer than a few days are of importance: No way I could recommend amdgpu, yet. There are just way too frequent spontaneous crashes, even when doing completely mundane stuff (like typing text into a web form :-( ).
    on the other hand if nobody uses the drivers they will never get better. No body likes crashes but unused software never crashes. You need to also consider that AMD hardware in the likes of Raven Ridge didn't work at all a few weeks ago.
    For the hardware I use for work, Intel's integrated GPUs are currently the only stable option I know.
    Intel does a very good job with open source. The only real problem is the poor GPU performance. I can get by with moderately good 3D performance doing light CAD and 3D work, AMD delivers that in their hardware. Yeah software could use some improvements but it is already vastly improved.

    I might also suggest that in the case of the hardware im running MS isn't all that far ahead. In the 3 months ive had this machine I've seen significant updates on basically a weekly schedule. I actually prefer to see Linux getting the attention even if driver improvements are still neded.

    Leave a comment:


  • pete910
    replied
    Originally posted by Brisse View Post

    It doesn't ACTUALLY work even if this flag is set to enabled. I am able to verify this because my monitor OSD is capable to show me the refresh rate as it changes in "real time", and on Linux it doesn't change at all despite xrandr reporting Freesync enabled. If you been following Phoronix news articles you would have seen that AMD developers are currently working with upstream developers to come to some vendor neutral solution to implement adaptive refresh rate in drivers and user space, but it's not finished and will probably take months, if not years before we see a working upstreamed implementation. Until then, AMDGPU-PRO is the only way to do Freesync on Linux and it is very limited in it's functionality compared to Freesync on Windows. Pretty much useless to be honest.
    My monitor also reports is active too when enabled. It works in game too if you have the framerate caped to the monitors refresh/freesync rate



    What do you mean by limited to windows, Used on both all though not much on windows if am honest ?

    Just thought am on AMD staging ! guess there,s still a fair difference between that and what's in mainline branch!

    Leave a comment:


  • juno
    replied
    Hmm, will be interesting to see how many will disable the default setting now...

    Leave a comment:


  • Jumbotron
    replied
    Originally posted by bridgman View Post

    I would say that enabling DC by default in amdgpu is a pre-requisite for enabling amdgpu by default - don't think it would make sense for them to happen together. At this point Mr Cooper usually reminds me about the other pre-requisite I'm forgetting...
    Once again, thanks Bridgman for the info. As I told someone else, I felt a little foolish when I saw I referenced 18.04 and tied it to DC. As the poster said perhaps by 18.04.1 or 2 or perhaps in my hope 18.10.

    Either way, a hearty mug of brew for all you and the AMD Linux team are doing for us !

    Leave a comment:

Working...
X