Announcement

Collapse
No announcement yet.

AMDGPU Changes Begin Queuing Ahead Of Linux 5.1 Kernel Cycle

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

  • #11
    Originally posted by Weasel View Post
    ...and everyone else asking for backports.

    See guys? This is one area where proprietary drivers are better than in-kernel drivers, Nvidia's blob included. They are independent and can be updated independently no need for a fucking backport or updating the entire god damn kernel.
    Sorry, but they are not better. Being proprietary just forces them to make it as a kernel module, but they also can lag behind supporting newer kernels and it surely doesn't guarantee them to work with older ones. dkms isn't infallible even if it offers some temporary flexibility. Besides, nothing stops AMD from offering amdgpu changes as a dkms option.

    Comment


    • #12
      Originally posted by debianxfce View Post

      Back porting is a waste resources, why on earth someone wants use old and buggy software.
      People work in HDR mainly for 3D Modeling and film, not video games, so having HDR enabled on hardware that guarantees it but never delivers is annoying.

      Comment


      • #13
        Originally posted by juno View Post
        And to add at least a little sense to my own post: HDR doesn't "slow down FPS" because every modern game is running a HDR pipeline already.
        Not only that, but the "compression" of colors to SDR is a processing step that can be saved. So in fact, native HDR would increase performance when hooked up to a monitor with native color support as written in the game code. (at least in theory)

        Comment


        • #14
          Originally posted by Weasel View Post
          See guys? This is one area where proprietary drivers are better than in-kernel drivers, Nvidia's blob included. They are independent and can be updated independently no need for a fucking backport or updating the entire god damn kernel.
          You don't need proprietary drivers - AMD open source drivers are available both upstream and packaged with DKMS/KCL "so that they are independent and can be updated independently".
          Last edited by bridgman; 01-16-2019, 03:26 PM.

          Comment


          • #15
            Originally posted by bridgman View Post

            You don't need proprietary drivers - AMD open source drivers are available both upstream and packaged with DKMS/KCL "so that they are independent and can be updated independently".
            Where exactly are amdpgpu dkms packages available though? Wasn't there some plan to make a Debian (and some other distros) repos for them? Would be useful to test latest amdgpu updates without recompiling the whole kernel, but at the same time that's all I need, I don't want to install the whole PRO bundle to get it.

            Comment


            • #16
              Originally posted by faph View Post
              and then:
              - Shader clocks and memory clocks are now exposed via hwmon interfaces.
              Fu**ing finally!
              What does this mean exactly? Is it just a readback or can I easily change the clocks with that patch?

              Comment


              • #17
                Originally posted by shmerl View Post

                Where exactly are amdpgpu dkms packages available though? Wasn't there some plan to make a Debian (and some other distros) repos for them? Would be useful to test latest amdgpu updates without recompiling the whole kernel, but at the same time that's all I need, I don't want to install the whole PRO bundle to get it.
                The packaged Linux drivers available at amd.com use dkms and support both a fully open stack and the closed source components for workstation. You can install just the open source packaged if you don't need the pro stuff. In additional, we provide our dkms git trees (e.g., https://cgit.freedesktop.org/~agd5f/...g/?h=amd-18.50 )
                if you want to adapt to support other kernels or distros we don't currently support.

                Comment


                • #18
                  Originally posted by Mathias View Post

                  What does this mean exactly? Is it just a readback or can I easily change the clocks with that patch?
                  It just exposes the current clocks via a hwmon compatible interface (e.g., freq1_input). hwmon does not actually technically support clock frequencies so it won't show up in standard hwmon tools like sensors.

                  Comment


                  • #19
                    Originally posted by agd5f View Post

                    The packaged Linux drivers available at amd.com use dkms and support both a fully open stack and the closed source components for workstation. You can install just the open source packaged if you don't need the pro stuff. In additional, we provide our dkms git trees (e.g., https://cgit.freedesktop.org/~agd5f/...g/?h=amd-18.50 )
                    if you want to adapt to support other kernels or distros we don't currently support.
                    Do you plan to use some standard distro repos for that? This way it won't require manual package installation and users will just select packages they need with apt-get or whatever.

                    Comment


                    • #20
                      Originally posted by agd5f View Post
                      hwmon does not actually technically support clock frequencies so it won't show up in standard hwmon tools like sensors.
                      But they do show up in debug sysfs now? I.e. you can see frequencies in amdgpu_pm_info for example.

                      Comment

                      Working...
                      X