Announcement

Collapse
No announcement yet.

AMD's Raven Ridge Botchy Linux Support Appears Worse With Some Motherboards/BIOS

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

  • #11
    We would not have deal with this mess Linux had stable driver ABIs within the same major release (similar to FreeBSD's driver model). Windows has good support for new hardware on because IHVs can prepare drivers in advance get the quirks ironed out before launch. With Linux you have upstream your drivers early and pray major distributions will pick them up before their hardware goes on sale, to make things more complicated new distro releases and hardware enablement updates rarely align with hardware launches.

    I know Linus and Co. will instantly reject any proposals for stable kABIs, you might be able to get away with not having one in server use cases (hardware architecture rarely change) but that has to be done if you want solid day-one support for new consumer devices similar to what Windows users have been enjoying for years, but I'm sure the sheeps on this forum will jump out and attack me for pointing this out.
    Last edited by FirstPersonBSOD; 19 February 2018, 09:32 AM.

    Comment


    • #12
      Originally posted by FirstPersonBSOD View Post
      We would not have deal with this mess Linux had stable driver ABIs within the same major release (similar to FreeBSD's driver model). Windows has good support for new hardware on because IHVs can prepare drivers in advance get the quirks ironed out before launch. With Linux you have upstream your drivers early and pray major distributions will pick them up before their hardware goes on sale, to make things more complicated new distro releases and hardware enablement updates rarely align with hardware launches.

      I know Linus and Co. will instantly reject any proposals for stable kABIs, you might be able to get away with not having one in server use cases (hardware architecture rarely change) but that has to be done if you want solid day-one support for new consumer devices similar to what Windows users have been enjoying for years, but I'm sure the sheeps on this forum will jump out and attack me for pointing this out.
      Well ... I have the HP Envy x360 with Ryzen 2500u ... there is one driver that actually works. ONE. And there is no official AMD driver, only the HP one .... There are reports on the net that the GPU drivers can be installed and work on some models/windows installs and give in the order of 15-30% more GPU performance. But sadly nothing works on my specimen.

      So the Windows driver support is not exactly better. This is endemic to AMD ... not Windows or Linux ...

      Comment


      • #13
        Originally posted by FirstPersonBSOD View Post
        We would not have deal with this mess Linux had stable driver ABIs within the same major release (similar to FreeBSD's driver model). Windows has good support for new hardware on because IHVs can prepare drivers in advance get the quirks ironed out before launch. With Linux you have upstream your drivers early and pray major distributions will pick them up before their hardware goes on sale, to make things more complicated new distro releases and hardware enablement updates rarely align with hardware launches.

        I know Linus and Co. will instantly reject any proposals for stable kABIs, you might be able to get away with not having one in server use cases (hardware architecture rarely change) but that has to be done if you want solid day-one support for new consumer devices similar to what Windows users have been enjoying for years, but I'm sure the sheeps on this forum will jump out and attack me for pointing this out.
        Hey. No attacks from me. I think you are correct that having a stable driver ABI would make it a lot easier for companies like AMD to ship a working driver for current distros. However I don't think what you have suggested is the clear obvious solution for these reasons:
        1. Having a stable driver ABI in the kernel has draw backs. If you have a stable ABI then by definition you cannot frequently update the ABI (braking backwards compatibility) in order to make the ABI more efficient when other changes have been made within the kernel. At this point the kernel devs have two choices:
          1. If possible, write intermediate code to sit between the stable ABI and the new kernel internals. This intermediate code would handle the differences between the stable ABI and the new kernel internals. There would be CPU & memory overheads due to this. Considering how low level the kernel is and how high the requirement is for the kernel to run fast, this overhead could be quite significant. This would make Linux less competitive, where people are opting to use it to get performance gains. (food fort though: perhaps GNU/Linux servers are often found to be faster and more stable than Windows servers in part because of the lack of driver ABI backward compatibility).
          2. Create a new ABI to more efficiently interface with the new, improved, kernel internals but also maintain the old ABI. This particular point will obviously incur a maintenance overhead and it requires all the work from point 1 is performed.
        2. Linux does have LTS releases. These don't have the stable ABIs you're referring to, but practically speaking, they do provide hardware makers a more stable target for their drivers. AMD could write a driver for the mainline kernel and test that driver on each of the support Linux LTS releases. If the driver doesn't work on the LTS releases, AMD could include temporary workarounds. AMD could then publish their driver for each of the LTS releases such that distros using these LTS kernels can compile in driver support. Not ideal, but it's better than nothing.
        3. This situation with unstable ABIs is foreseeable by AMD and other hardware makers. They compete in a fast moving world, but they probably could make adjustments to their internal processes to get their driver into the kernel faster than they are currently doing. I don't know this for sure, but there is almost always room for improvement in every organisation.

        Comment


        • #14
          Originally posted by debianxfce View Post

          Current speed that AMD has to match mainline kernel version is just fine. Now the ~agd5f/linux/log/?h=drm-next-4.17-wip kernel is in version 4.15-rc8 and that is just fine. Soon it will be in version 4.15.X or 4.16-rcX. AMD, nvidia and intel can live with kernel changes.

          I know you were meaning the mainline kernel, but that has had a partially implemented amdgpu for years and clever AMD gpu users are not interested. Most important is to have drivers from somewhere and distribution kernels are slow. So no matter what, you are still using custom kernels.
          I've been using custom kernels for longer than I've been using distro kernels, that's half the fun for me

          Comment


          • #15
            Originally posted by FireBurn View Post
            I'm going to wait and get a mini-ITX X470 or B450 board when they come out, assuming of course they have a HDMI 2.0 connector on them #cantWait #isItMarchYet

            Originally posted by msotirov View Post
            This. HDMI 2.0 is a must. Sadly most current AMD mini ITX motherboards don't have HDMI 2.0 or more than one Displayport.
            They do have HDMI 2.0, even if they don't list it. The port on the board is literally just that, the physical port, it is wired to the APU, so if the APU supports HDMI 2.0 then the port is a HDMI 2.0 port.

            With AM4 what HDMI or Displayport version is supported is dictated by the APU alone, the chipset on the motherboard has nothing to do with it.



            Comment


            • #16
              The best case scenario would probably be development staying in git but with regular backports to LTS. Unfortunately I seriously doubt AMD has a large enough Linux team to make that happen. Even with more developers they would be better off focusing on git to keep the drivers evolving.

              Comment


              • #17
                Originally posted by Spazturtle View Post
                They do have HDMI 2.0, even if they don't list it. The port on the board is literally just that, the physical port, it is wired to the APU, so if the APU supports HDMI 2.0 then the port is a HDMI 2.0 port.

                With AM4 what HDMI or Displayport version is supported is dictated by the APU alone, the chipset on the motherboard has nothing to do with it.
                No exactly true. There are physical requirements for various HDMI versions. The OEM has to validate the port for the version of HDMI they want to support. The driver checks the connector tables in the bios provided by the OEM to determine what connectors are present and what they support.

                Comment


                • #18
                  Most of our Linux testing/validation is done on reference platforms. In general, specific platform validation is done in conjunction with the OEM. The OEM requests what OSes are supported/validated for their individual programs.

                  Comment


                  • #19
                    I've been waiting for this CPU since I heard about it and when Michael started testing it I joined Phoronix plus a $5.00 tip. Now I feel guilty about how much frustration he's saved me by going through all this misery and sparing me from having to do so. A $5.00 tip isn't worth the trouble. When Kaveri came out, I was stuck with fglrx but at least it worked and the system was stable. This is a whole 'nother mess.

                    Thank you for your efforts Michael, I really hope this stuff gets worked out because the 2[2/4]00G chips look very interesting.

                    I love building a new computer but this one is going to have to wait.

                    Comment


                    • #20
                      Originally posted by _Alex_ View Post
                      While I don't want to compare, at least Intel stuff generally plays under linux...
                      If only.. Look up Atom BayTrail and CherryTrail random crashes.

                      Originally posted by _Alex_ View Post
                      and this thing has become a factor where you see an AMD product that is attractive but you kind of expect that it will fail in a hundred different ways under linux and thus you tend to avoid it. So you end up choosing a less attractive Intel product instead - when you shouldn't have to do that.
                      I've had less issues on Linux with AMD CPUs and GPUs than Intel's and Nvidia's for many years now.

                      Comment

                      Working...
                      X