AMDGPU Changes Begin Queuing Ahead Of Linux 5.1 Kernel Cycle

[shmerl]

...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.

[Marc Driftmeyer]

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.

[Shevchen]

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)

[bridgman]

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".

[shmerl]

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.

[Mathias]

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?

[agd5f]

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.

[agd5f]

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.

[shmerl]

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.

[shmerl]

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.