Announcement

Collapse
No announcement yet.

AMDGPU Sends In More Linux 5.1 Updates With Seamless Boot Bits, FreeSync Fixes

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

  • #11
    Originally posted by humbug View Post
    AMD, please make the newer kernel driver the default for sea islands on kernel 5.1
    are you asking for breaking all stuff unimplemented in amdgpu for cik, or for fixing it in amdgpu first?

    Comment


    • #12
      Originally posted by Lanz View Post
      Still waiting for AMDGPU DC to not lock up the system while playing CS:GO on my Vega 64.
      Odd, Fine for me on battle royal mode , been a long while since I played normal

      Comment


      • #13
        I'm still stuck on 4.18.20, which is now unsupported, because resume from suspend still doesn't work on the Sapphire Nitro R9 390. I've tried in vain for about two man weeks of time to bisect the problem, but the 4.19 release is such a mess it doesn't seem possible.

        The problem is that 4.19.7 is the first version that even booted with it, as 4.19.0 to 4.19.6 were completely broken. So when you try to bisect there's no way to reliably detect what's "good" and "bad", you just have to say everything is bad until it at least boots. And by that time whatever causes the resume failure has already been committed, because once it finally boots the resume error is already there.

        And by the way I've tried starting and stopping the bisect at numerous points, from the logical "good" version of 4.18.20 and "bad" version of 4.19.7, to many variations below and above. But it doesn't matter where you start and stop, and often the whole bisect breaks down and you just have to start manually reconfiguring the kernel so it at least compiles.

        And the worst part? As of yesterday the drm-next and amd-wip kernels are still broken.

        I bought this card three years ago now, when it was touted as one of the latest and greatest by AMD. And almost as soon as I bought it AMD abandoned Linux to, well, whatever. And now they won't even use one of the own R9 390s to fix this problem. And with all the other problems that have come and gone, I've only been able to use my expensive card for about six months, intermittently, out of those three years.

        I wonder if anyone from AMD wants to make an excuse for that?

        Comment


        • #14
          Originally posted by pal666 View Post
          are you asking for breaking all stuff unimplemented in amdgpu for cik, or for fixing it in amdgpu first?
          Obviously if it's important it needs to be implemented. What features in particular are you talking about which are still pending? It's been a very long time for 'experimental support'.

          on my r9 290 amdgpu is better than radeon now, has been for a while.


          Comment


          • #15
            Originally posted by humbug View Post
            Obviously if it's important it needs to be implemented. What features in particular are you talking about which are still pending? It's been a very long time for 'experimental support'.

            on my r9 290 amdgpu is better than radeon now, has been for a while.

            Good god humbug.

            Resume from suspend is not important?

            Comment


            • #16
              Originally posted by muncrief View Post

              Good god humbug.

              Resume from suspend is not important?
              Who said it's not important?

              I asked the question about which features are pending after all this time because I wanted to know.

              Comment


              • #17
                I really hope that AMD brings the RGB Control Feature to Linux..

                I own Saphire Cards, and I can't look to them, it really hurts my eyes,
                Also that feature consumes power.

                AFAIK, on linux we have no way to disable it..

                Comment


                • #18
                  RGB Control Feature ? Do you mean for the LEDs on Sapphire cards ? I'll try to find out, but off the top of my head I didn't think we designed the hardware or wrote the software for that.

                  EDIT... poking around in a similar tool for MSI cards suggests that we have an ADL call to control illumination, but I don't think I am seeing it in the ADL documentation so the LED controls may require info from the board partners that we can't expose.

                  https://github.com/Vipeax/MSI-LED-To...ool/Program.cs

                  https://github.com/GPUOpen-Libraries...isplay-library

                  Best guess is that the board vendors are adding their own ADL extensions, although that won't help with Linux because we are using sysfs rather than ADL for driver control these days.
                  Last edited by bridgman; 10 February 2019, 01:54 PM.
                  Test signature

                  Comment


                  • #19
                    I'm still waiting for 120Hz 2880p displays, which should be supported just fine with Vega 64 but just don't seem to exist on the market yet.

                    Comment


                    • #20
                      Originally posted by microcode View Post
                      I'm still waiting for 120Hz 2880p displays, which should be supported just fine with Vega 64
                      supported as in "can move windows"
                      not supported as in "can play modern game on max settings"

                      Comment

                      Working...
                      X