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

  • #21
    Originally posted by Azultra View Post
    If only.. Look up Atom BayTrail and CherryTrail random crashes.


    I've had less issues on Linux with AMD CPUs and GPUs than Intel's and Nvidia's for many years now.
    I remember reading here on Phoronix, last year I think, about problems on the Intel GPU drivers and lots of people on Phoronix forum, telling about their problems on modern generation hardware, while mine old Ivy Bridge was working fine.

    And about the old tale of working Windows drivers, their support forums tells another history.

    Comment


    • #22
      I have an aesthetic's question, ``What's with all the cheap casing you possess. Spend a $. You're getting tens of $'s on what mustn't be a great ROI for AMD, Intel or Nvidia [size of the Linux consumer market] and yet I see cheap power supplies, cheap cases in most of your equipment, sans the Threadripper/EPYC systems fully ready and sent to you.

      Comment


      • #23
        Interesting thread and to be honest im in the group that is a bit disappointed with AMD. Im cutting them some slack because Meltdown and company have sat kernel development back at least two months in general. This focus on Meltdown and company has slaughtered distro support for new hardware. So that is part of the problem.

        However AMD needs to do better in regards to making binaries available for hardware. Im one of those with the HP ENVY and frankly just finding the materials to do a bootsble installation is asnine, AMD really needs a dedicated Linux support site. So yeah huge issues with the way AMD does things.

        Now for drivers and support i might mention that not even Windows was completely ready for the HP ENVY. In that regard ive recieved many updates of late that have dramatically impacted performance under Windows. So it is reasonable yo say that even Windows support is constantly improving on this hardware. The frustration isnt unique to Linux.

        Im holding out for a stable distro in March or April. I really dont like the idea of running developmental distros.

        Comment


        • #24
          Ok, so I do sort of agree that AMD's -in house- quality control isn't that good. It's the reason why newly released code from them is always so buggy. But that's not linux's fault, in all cases so far the code was fixed and stabilized once upstreamed. I've also come to believe AMD uses code generators to write a lot of it's code, which is then half-assed attempt to document, most times with the only documentation being in the code comments or the code itself. I think that's the reason why so much of AMD's code is so horribly abstracted, I think most of it was generated.

          Comment


          • #25
            Originally posted by duby229 View Post
            I think that's the reason why so much of AMD's code is so horribly abstracted, I think most of it was generated.
            Can you give an example? The only things that are generated in the kernel are the register and packet headers and the bandwidth calculation code in DC.

            Comment


            • #26
              This article right here explains why Linux, despite being around over 2 decades, can't even manage to get more than 1 percent of the desktop. One can argue that Linux and Unix based OSes are superior to Windows in many ways but one way that they obviously aren't is in the way drivers are handled. As much as I can't stand Windows past Win 7, the one thing I have to admit is that you can take a copy of Win 8 or 10, install it on the latest hardware, it will start with generic or MS signed drivers and then you can install the supplied drivers from either the manufacturer's website or from the included cd and be on your way.

              With Linux you can't do that, you need to wait for the support to be built into the kernel, which means that you can't run the latest hardware from day one. And it's not an AMD thing, reading previous articles, the same issues have reared their head with Intel integrated graphics.

              Linux and Unix needs to rethink the driver model that's used, one should be able to install a driver for a device without needing to rebuild the kernel or having to wait for the kernel maintainers to decide to include support for a given device.

              Until then Linux is destined to be a footnote in the history of computing.

              Comment


              • #27
                Originally posted by agd5f View Post

                Can you give an example? The only things that are generated in the kernel are the register and packet headers and the bandwidth calculation code in DC.
                What I meant was that I think a lot of AMD code itself was generated with some sort of C generator.

                Comment


                • #28
                  Things tend to work better on validated platforms for bleeding edge hw. That's how other OSes and OEM pre-loads work. The OEM works with the platform vendor and OS vendor to validate a specific combination of drivers and OS versions. For better or worse, the entire industry follows this model. It's impossible to test every combination of kernels and distros a user might try. Ultimately things improve as all of the platform specific quirks make their way into all of the relevant upstream components. Unfortunately, Linux has a relatively small market share so it does not get the same level of OEM engagement as other OSes.

                  Comment


                  • #29
                    Originally posted by zoomblab View Post
                    I have been burned with my older Radeon 7870 which IMO has always been in eternal beta support level
                    this is gcn 1.0 and i have several gcn 1.0 cards working flawlessly for many years. check /dev/hands ?
                    Originally posted by zoomblab View Post
                    , plus I don't like the way AMD has went with their multiple drivers
                    amd has only one driver(radeonsi), if you are using something else, it explains all your issues
                    Originally posted by zoomblab View Post
                    that never work 100% properly. So I got a Ryzen 1700 with an 1050 Ti. A bit more expensive combination with closed driver but you know what? It works perfectly and also I didn't have to upgrade half of my OS stack to get it working!
                    ryzen with non-nvidia driver also works properly and by properly i mean really properly, not nvidia-way "properly"
                    Originally posted by zoomblab View Post
                    AMD people, I do appreciate your hard work and support for Linux BUT please consider to put the end user experience at the center of your software strategy and try to be competitive with what Nvidia offers in that respect. For me open source is a plus but is not the end goal.
                    they already put your experience better than nvidia. you just install sane distro and everything works out of the box. it is only when your hands are crooked, then you go and download "drivers" from internet and complain how nvidia is better than working out of the box

                    Comment


                    • #30
                      Originally posted by agd5f View Post

                      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.
                      All the people testing it and saying HDMI 2.0 works are on Windows, so I guess the Windows driver is just ignoring the connector table.

                      Comment

                      Working...
                      X