Announcement

Collapse
No announcement yet.

It Doesn't Look Like A Ryzen/EPYC Thermal Driver Will Make It For Linux 4.14

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

  • #11
    Originally posted by trivialfis View Post
    I am not familiar with the internal of Linux. But I think it supports dynamically loaded modules. I don't understand why does the kernel have to include these drivers' complete source code. Can people just compile the latest GPU module as .ko and then load it into the kernel?
    regarding the GPU : no you can't easily.
    (you're at risk of getting error message regarding wrong version of kernel API when you try to compile).

    The GPU is a nice example of why not.
    A modern system like Linux is an extremely complex beast with a tons of component all in interplay.
    regularily when you edit is small part somewhere it can have repercussion on all the parts that rely on it.

    the graphical stack in Linux is in a constant evolution, there are constantly new elements and new capabilities added, meaning the way all the modules talk to each other evolves and the drivers must be adapted to that.

    if a driver's source is part of the kernel tree, that means it's accessible to all the developers. if somebody change the way some thing are handled and it has an impact on GPU drivers, they can fix/update the GPU drivers, that's why all the drivers that are part of the kernel (e.g.: Radeon, Intel) always "just work" as the kernel updates - they are modified to follow the latest upgrades.

    if a driver is out of tree, the developers responsible of the kernel that upgrade it can't upgrade the driver too. It's up to the devs of the driver to fix their code to follow the latest evolutions of the linux driver.
    That why 3rd party proprietary drivers like Nvidia's are a bit problematic on "rolling" distros, and why there's a delay between a new linux kernel and when these driver finally get to work.

    ----

    Now in the specific case of a CPU thermal device :
    these are much simpler, there's a lot less thing interplaying with each other, chances are high that you'll be able to grab some beta code somewhere, sucessfully compile a .ko driver and load it into the kernel.

    I think that since the last overhaul of the "i2c" driver and "hwmon" stacks, we haven't seen much modification impacting the way thermal works.

    Also :
    - some motherboard are able to monitor the CPU temperature themselves, and you could ask the motherboard through ACPI.
    - some motherboard feature extra sensors, some of which could also measure the CPU temperature separately. You can either ask that sensors for the temperature directly, e.g. using an appropriate i2c driver. Or check if that sensors is available on one of the standard API of the motherboard (like ACPI).



    Comment


    • #12
      While a Zen thermal driver isn't really a 'must' for most people in the sense that you need one to have a working system or be able to see cpu temps (a lot of motherboards have their own sensors which are supported) it is a 'must' in the sense that a thermal driver is a pretty simple piece of code for AMD to write and makes your product look much more mature.

      And in b4 someone says 'if it's that simple write it yourself' buy be a few ryzen based computers (you know more than one for testing)... like 1 Ryzen 7 1700, one Threadripper 1950x and one dual cpu Epyc (with however the 32c/64t cpus are called).

      Comment


      • #13
        Originally posted by trivialfis View Post
        I am not familiar with the internal of Linux. But I think it supports dynamically loaded modules. I don't understand why does the kernel have to include these drivers' complete source code. Can people just compile the latest GPU module as .ko and then load it into the kernel?
        Linux kernel API (the kernel-driver interface) is not stable for performance reasons (it is subject to change whenever it would yield a performance benefit, and this happens quite a bit), and due to technical reasons it's unpractical to have a stable binary kernel interface (to run pre-compiled drivers) too.

        Although most distros sidestep the binary kernel interface issue by shipping their own compilers and their own kernel configuration so you can compile the driver module with the exact same compiler and exact same kernel configuration as used in the distro, so the new module will work fine.

        So for example you can install NVIDIA or ZFS or other drivers that are shipped as source (or have a source part) which has to be compiled on your PC before being loaded. It's usually quick enough to not be a major issue.

        The main issue is changes in the kernel API. All drivers are in the kernel repo so they are updated together with the API change (the person/team that changes the API is responsible of adapting the other drivers too), drivers kept separate need to be updated by someone when the API changes, NVIDIA or the ZFS driver team does that for example.

        A good read on why Linux is like this is in this documentation file found in the linux kernel source https://github.com/torvalds/linux/bl...i-nonsense.rst
        Last edited by starshipeleven; 09-03-2017, 09:22 AM.

        Comment


        • #14
          I google this as I try to check my ThreadRipper temperature.. Sad news indeed. I have also worked on it87 source code before. Its a little tricky sometimes without good documentation. TR and Ryzen also have temperature offsets to deal with. I hope AMD can clear the legal bamboozling to get the data out soon. Its hard to please everyone, and sometimes you have to follow the money (Windows) first. How do you have day1 open source drivers without spilling the beans on proprietary information before launch?

          Comment


          • #15
            Seems that FreeBSD ppl had it figured out https://bugs.freebsd.org/bugzilla/sh....cgi?id=218264

            Comment


            • #16
              Originally posted by kevinf28 View Post
              How do you have day1 open source drivers without spilling the beans on proprietary information before launch?
              What we are working on is open source drivers which install like proprietary drivers.

              We switched the internal AMDGPU-PRO builds over today to start including an all-open install option as well. Still needs a pile of testing and fixing - I think 17.50 is ETA for shipping - but it is making progress.

              Comment

              Working...
              X