Announcement

Collapse
No announcement yet.

AMD Sends In More Radeon "Navi 2" Updates For Linux 5.10 Kernel

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

  • AMD Sends In More Radeon "Navi 2" Updates For Linux 5.10 Kernel

    Phoronix: AMD Sends In More Radeon "Navi 2" Updates For Linux 5.10 Kernel

    AMD's open-source Radeon Linux graphics driver developers have sent in their first round of updates to DRM-Next ahead of the Linux 5.10 kernel merge window kicking off in October...

    http://www.phoronix.com/scan.php?pag...nux-5.10-First

  • #2
    I think the thing called "runtime pm" here is not the normal down/upclocking of memory and GPU frequency, but rather the new BACO stuff where you turn the whole chip off and stuff like that.

    Comment


    • #3
      I sure hope AMD is actually bringing some thing other than excuses with Big Navy.

      Comment


      • #4
        Originally posted by MadeUpName View Post
        I sure hope AMD is actually bringing some thing other than excuses with Big Navy.


        Ahoy!

        I feel like my rx5700 is going to last me a long time for 1080p, might have to make the switch to a higher resolution down the line if performance/watt improves so much. Looking forward to see what team red and team green come up with.

        Comment


        • #5
          The problem is what you expect and in which environment - which gets clear if we try to get a feeling by looking back to RDNA1 = Navi (1):

          So `baseline' should be defined ... if it would be stable and full desktop (e.g. incl. temperature monitoring conky) it must be Linux 5.6 - or even 5.8 (incl. a lot of important patches for RDNA1).
          On the other side, RDNA1 like Navi 10 had initial support with 5.3 cited by Phoronix to be ready for using it, but a stable desktop could not be reached with this setting (rhytmical sleeping and crashes are not funny ). The baseline for Navi 1 (confusing - I thought Navi is just the codename for RDNA1? - but anyway) is at least Linux 5.6 and recommended may be 5.8 (bringing up additional functionality) ... not to speak about missing ROCm support right now ... which is part of functionality as well as a user space tool for configuring it.

          Thus thinking of RDNA2 / Navi2 may not be that severe as no new architecture is introduced, but there are enough changes and even new functionality that 5.11 may be an optimistic baseline to really work with it - only time will tell - but a lot of patches for 5.10 shows that functionality and thus stability can not be reached with 5.9 - and I doubt 5.10 will do it.

          As the proprietary drivers are no match and officially supporting only absolutely outdated releases, Kernel and Mesa with full support early are decisive so that distributions available at launch do have support. Thus I really do hope that AMD invest heavily in open source programmers to do the heavy lifting fast and distros can see stable support from day 1. Currently we are more than a few months off.
          That said, Navi 10 is great performance-wise and stable with Linux 5.7 and Mesa 20.1 - so first distribution to officially support it seems to be Groovy [and thus also Ubuntu 20.04.2 LTS `Focal']:
          that means distro released 10/2020 for a card released 07/2019, i.e. *15 months* after release of a distro supporting it properly (Ubuntu 20.04 LTS `Focal' was a really bad choice using 5.4 Kernel, so it is not fully to be blamed on AMD - Ubuntu/Canonical should have used 5.6 instead - and it has on OEM kernel in the PPA which really helps).

          And as given before: with a much better performance per watt ratio Navi 2 would be very interesting ... and I am longing to see a real RDNAx APU with 8k support via DP 2.0 (as DP 2.0 was expected this year and Navi APU is not announced yet it would be a nice fit) - and no longer those old architectures not optimized for 4k and 8k (info from AMD - as Navi 10 was 1st card advertised as optimized for those current high resolutions) and APUs even restricted concerning resolution.
          APUs of cause are solutions to work with - with a great performance per watt (i.e. *silent*) and still good performance - but not a solution for gamers which still do need dGPUs for playing 4k+ titles with nice framerates .

          Comment


          • #6
            Originally posted by Linux_Chemist View Post


            Ahoy!

            I feel like my rx5700 is going to last me a long time for 1080p, might have to make the switch to a higher resolution down the line if performance/watt improves so much. Looking forward to see what team red and team green come up with.
            I was in the same position editing upscaled 4K on from the EOS-R on the RX-580. . I would have been OK with that indefinitely. Did it do every thing in real time? No but it was good enough to not be a total PITA. But then I bought a BMPCC 6k and I am now shooting every thing 6K RAW. The 580 is on it's knees even with proxies, optimized media, 1/4 scale playback etc. While the image quality is incredible the turn around time for projects is unworkable. So I am in the boat of waiting for AMD and NVidia to finish announcing so I can determine what to buy. Nvidia has just launched their new hotness and AMD isn't going to be to far away. But it is looking like AMD isn't going to be even remotely competitive on the graphics side any more.

            Comment


            • #7
              Originally posted by MadeUpName View Post

              I was in the same position editing upscaled 4K on from the EOS-R on the RX-580. . I would have been OK with that indefinitely. Did it do every thing in real time? No but it was good enough to not be a total PITA. But then I bought a BMPCC 6k and I am now shooting every thing 6K RAW. The 580 is on it's knees even with proxies, optimized media, 1/4 scale playback etc. While the image quality is incredible the turn around time for projects is unworkable. So I am in the boat of waiting for AMD and NVidia to finish announcing so I can determine what to buy. Nvidia has just launched their new hotness and AMD isn't going to be to far away. But it is looking like AMD isn't going to be even remotely competitive on the graphics side any more.
              Looking the console designs and the HUGE power figures Ampere requires, AMD can do still very well in graphics, they started hyping some announcements as soon as nvidia did the RTX Ampere reveal, so, they are at least confident about what they have.

              Comment


              • #8
                [QUOTE= The baseline for Navi 1 (confusing - I thought Navi is just the codename for RDNA1? - but anyway)
                [/QUOTE]

                Radeon RX 5000 series
                Codename = Navi
                Architecture = RDNA1

                Next AMD video card series
                codename = "BigNavi" (Not 100% but have seen this codename being used to online.)
                Architecture = RDNA2
                Last edited by castlefox; 09-04-2020, 08:52 PM.

                Comment


                • #9
                  Originally posted by JMB9 View Post
                  The problem is what you expect and in which environment - which gets clear if we try to get a feeling by looking back to RDNA1 = Navi (1):

                  So `baseline' should be defined ... if it would be stable and full desktop (e.g. incl. temperature monitoring conky) it must be Linux 5.6 - or even 5.8 (incl. a lot of important patches for RDNA1).
                  On the other side, RDNA1 like Navi 10 had initial support with 5.3 cited by Phoronix to be ready for using it, but a stable desktop could not be reached with this setting (rhytmical sleeping and crashes are not funny ). The baseline for Navi 1 (confusing - I thought Navi is just the codename for RDNA1? - but anyway) is at least Linux 5.6 and recommended may be 5.8 (bringing up additional functionality) ... not to speak about missing ROCm support right now ... which is part of functionality as well as a user space tool for configuring it.

                  Thus thinking of RDNA2 / Navi2 may not be that severe as no new architecture is introduced, but there are enough changes and even new functionality that 5.11 may be an optimistic baseline to really work with it - only time will tell - but a lot of patches for 5.10 shows that functionality and thus stability can not be reached with 5.9 - and I doubt 5.10 will do it.

                  As the proprietary drivers are no match and officially supporting only absolutely outdated releases, Kernel and Mesa with full support early are decisive so that distributions available at launch do have support. Thus I really do hope that AMD invest heavily in open source programmers to do the heavy lifting fast and distros can see stable support from day 1. Currently we are more than a few months off.
                  That said, Navi 10 is great performance-wise and stable with Linux 5.7 and Mesa 20.1 - so first distribution to officially support it seems to be Groovy [and thus also Ubuntu 20.04.2 LTS `Focal']:
                  that means distro released 10/2020 for a card released 07/2019, i.e. *15 months* after release of a distro supporting it properly (Ubuntu 20.04 LTS `Focal' was a really bad choice using 5.4 Kernel, so it is not fully to be blamed on AMD - Ubuntu/Canonical should have used 5.6 instead - and it has on OEM kernel in the PPA which really helps).

                  And as given before: with a much better performance per watt ratio Navi 2 would be very interesting ... and I am longing to see a real RDNAx APU with 8k support via DP 2.0 (as DP 2.0 was expected this year and Navi APU is not announced yet it would be a nice fit) - and no longer those old architectures not optimized for 4k and 8k (info from AMD - as Navi 10 was 1st card advertised as optimized for those current high resolutions) and APUs even restricted concerning resolution.
                  APUs of cause are solutions to work with - with a great performance per watt (i.e. *silent*) and still good performance - but not a solution for gamers which still do need dGPUs for playing 4k+ titles with nice framerates .
                  You make a great point about "baseline" since not all features might be ready for everyone yet.
                  Didnt know that there was still important updates rolling out with linux 5.8. I thought things were in a much better position with Ubuntu 20.04 + 5.4 kernel. Thanks for the info.

                  I am using a GTX 770 and I have been holding out for the next AMDs RDNA2 video cards to upgrade. I REALLY hope the RDNA2 gets better initial support than the first RDNA cards. I have been using linux for while but I dont feel confident in my linux skills yet to buy a RDNA2 video card until it is stable and works great out of the box with Ubuntu. (without having to upgrade linux kernals / mesa)
                  Last edited by castlefox; 09-04-2020, 08:55 PM.

                  Comment


                  • #10
                    Originally posted by castlefox View Post
                    I have been using linux for while but I don't feel confident in my linux skills yet to buy a RDNA2 video card until it is stable and works great out of the box with Ubuntu. (without having to upgrade linux kernels / mesa)
                    I am pretty sure that there are many people which can work/game with Ubuntu 20.04 Focal and Navi 10 - it depends on the things one may use.
                    One big problem was in getting the temperature monitoring - which I have always done and will especially do so on new systems.
                    The second thing is that I test a lot - and try a lot of games. Thus there are restrictions e.g. to need Vulkan in a compliant form for several games (for Navi 10 the minimum is in that respect Mesa 20.0).
                    For computing stuff Navi 10 is still not suited due to the lack of ROCm support - just a matter of time, of cause.
                    So my needs (full desktop, current temperature value, full game compatibility, stable) are pleased with Linux 5.7.19 and Mesa 20.1.5 - i.e. no computing and no tweaking around (both are important for many people and are missing/lacking).

                    For a new card it must be installable via a standard boot image of the aimed at distribution - and Navi 10 was installable with Eoan 19.10 (about 3 months after release of Navi 10) and above - so Focal was more than suited to turn the lights on.
                    After that, I made a dd of the partition - changing UUID of cause from the clone - and than playing with it in respect of Kernel & Mesa:
                    1) Ubuntu Mainline Kernel: https://kernel.ubuntu.com/~kernel-ppa/mainline
                    for all kernels (you can chose old and current ones, even -rc; e.g. 5 deb packages - here for standard usage `generic':
                    linux-headers-5.7.19-050719 linux-headers-5.7.19-050719-generic linux-image-unsigned-5.7.19-050719-generic linux-modules-5.7.19-050719-generic;
                    i.e. putting the *.deb files in one directory and installing them via invoking `sudo dpkg -i *.deb' in that directory;
                    with boot managers like grub one can directly chose the former one if severe problems emerge).
                    2) https://launchpad.net/~ernstp/+archive/ubuntu/mesarc
                    for (quite) stable Mesa. Unfortunately it currently follows the 20.2-rc track i.e. ended with 20.1.5 (current is 20.1.7).
                    But with 20.2.x (x may be chosen by pressure to solve something or trying to reach a stable system in a more conservative way ...) it will get ideal again. Selecting the former Mesa would be problematic ...
                    But saying this I followed both PPAs closely and get only improvements during this ride.

                    From my point of view I would like Ubuntu (and its flavors - like Kubuntu - or derivatives like KDE Neon) and other desktop oriented distros getting to a rolling release model following mainline stable (Kernel, Mesa, X.org, applications (already done by the only applications I would not update at all due to the disruptive changes: Firefox and Thunderbird ... - only the compiler/libs should not be upgraded without heavy testing of staying binary compatible - same for all programs in the phase of getting a full new release out).
                    One should keep in mind that a kernel may have changes even in FS domain - and making use of new features would require updates in user space, too.
                    These may be done by a rolling release - not feasible with PPAs, as this would mean building an entire distribution.
                    And from that rolling release branching the extremely tested and rock solid LTS releases - which are really stable when old - same story.

                    GNU/Linux distros would be shining on the desktop if the entire stack would keep the kernel rule "never break userspace" ... (isn't it strange that playing old DOS games is no problem under Linux while starting an original Loki port is nearly impossible - which may be soon the case for any 32 bit Linux binary) and than such foolish ideas like snapd or flatpak would never be used on the desktop.
                    And any distro would immediately support new HW when that support entered mainline. For graphics cards this would be really wonderful.
                    Just a dream ... ... but it could come true if a consensus could be reached by all involved teams/developers/hackers ... and all support full functionality via the free stack - no proprietary drivers involved at all.
                    Something like a gold standard even to be kept by those releasing proprietary software (which is always 2nd class from a technical point of view).

                    Comment

                    Working...
                    X