Tweet
Originally posted by Sonadow
View Post
-
Lol. Have you checked what frequencies it's running at? Temperatures? Current/voltage? If it's running at 500 MHz at 100 degrees celsius, you very much care. Man, cut the trolling and bullshit.
-
Yeah, and if AMD hadn't provided current, voltage, power and temperature monitoring on Windows, they'd be absolutely shat upon. They would NOT be getting good reviews at all.Originally posted by duby229 View Post
In the case of GPU drivers, if they said "Hey, we're not going to have working support on launch day, and you need to compile some software for half-baked support, which is very buggy, and many bugs won't get fixed for months or even years. Also, some features won't ever be supported, but we'll charge you for the hardware all the same." they would be crucified. AMD's Linux support is just shit when compared to Intel and NVIDIA. NVIDIA may have a closed source driver, and politics around Wayland, but their driver is still pretty damn good.Comment
-
It's a multi-billion dollar company, not some three person band working out of a garage, or fledgling startup. They have the resources. They just don't give a crap.Originally posted by drakonas777 View PostComment
-
We are talking about CPUs. There is no such thing as "providing documentation on sensor interface for Windows". Linux will use the very same interface unless AMD is also providing binary driver to read the the sensor. Was HWMonitor was provided with such information by AMD? Or did they played guessing game. I just can't understand why CPU sensor (that is not provided via chipset I assume) support is not equal on all platforms. Did AMD provide specs under NDA? Is the NDA (and inability to publish sensor interface specs in kernel docs) the only problem and by dropping it, kernel devs want to convince AMD not to treat this the most basic thing not as trade secret?Comment
-
There is a difference between giving no crap and making some task low priority. I understand a dissatisfaction regarding this, but a few self-centered Linux users not being able to jerk off against 5950X stats is not that critical issue my friend.Originally posted by sandy8925 View PostComment
-
If you're willing to go the undocumented route, you can try: https://github.com/leogx9r/ryzen_smuOriginally posted by sandy8925 View Post
This uses the same interface Ryzen Master does while providing more info to boot. Using it, it's not exactly difficult to overclock on Linux using it. I've actually been using this to apply overclocks at the time or adjusting things like PBO limits. Ditto for voltage and temperature sensors, there's *far* more info the processor can reveal, unfortunately AMD just doesn't want to show it, muchless document the damn thing.
P.S. Broken voltage sensors on v5.10 for Zen 2 are due to the addition of Zen 3 patches which incorrectly modified Zen 2 stuff. Offsets used for Zen 3 are being (incorrectly) used on Zen 2, causing that 1.55/1.6V reading on v5.10 since those addresses aren't present on Zen 2.Comment
-
The documentation is largely tied up in hardware design documents and windows driver code. The HW, FW, and SW teams are really close at AMD there is not a lot of separation like there is at other companies. So providing documentation would require someone to talk to the HW or FW teams or go through the hardware design documents or windows source code and distill what you need to get the information. On top of that, at least on newer chips, the interfaces tend to be tuned for different markets (servers, client, etc.) so the APIs may not be consistent in all cases (e.g., client parts support overclocking, server parts do not).
Moreover, as far as I know, windows does not even have a standardized API like hwmon, every vendor provides their own app or interface to support various sensors. On windows, the average user probably never even installs Ryzenmaster. ACPI and the FW on the chip take care of thermals and clocking. The telemetry data is nice to have, but it's not like the system is unusable. As bridgman has said, getting feature parity with windows requires a comparably sized team. At the moment Linux market share for client parts is probably still in the single digits even if the real numbers are higher than what is commonly reported. I would love to see good hwmon support for the CPU. I care about it. We expose it all on the GPU side already and have for years, but there is not enough time in the day for me as it is. As OEMs start to push for more feature parity with windows client parts, I think we will start to see things improve on the client CPU side.
At least for APUs starting with renoir, there is already documentation on how to get the telemetry data from the CPU. You can query the CPU data via the same interface the GPU driver uses (see the metrics table):
Comment
-
This answers every problem I had with your last post. This is concise and very well written.Originally posted by agd5f View PostThe documentation is largely tied up in hardware design documents and windows driver code. The HW, FW, and SW teams are really close at AMD there is not a lot of separation like there is at other companies. So providing documentation would require someone to talk to the HW or FW teams or go through the hardware design documents or windows source code and distill what you need to get the information. On top of that, at least on newer chips, the interfaces tend to be tuned for different markets (servers, client, etc.) so the APIs may not be consistent in all cases (e.g., client parts support overclocking, server parts do not).
Moreover, as far as I know, windows does not even have a standardized API like hwmon, every vendor provides their own app or interface to support various sensors. On windows, the average user probably never even installs Ryzenmaster. ACPI and the FW on the chip take care of thermals and clocking. The telemetry data is nice to have, but it's not like the system is unusable. As bridgman has said, getting feature parity with windows requires a comparably sized team. At the moment Linux market share for client parts is probably still in the single digits even if the real numbers are higher than what is commonly reported. I would love to see good hwmon support for the CPU. I care about it. We expose it all on the GPU side already and have for years, but there is not enough time in the day for me as it is. As OEMs start to push for more feature parity with windows client parts, I think we will start to see things improve on the client CPU side.
At least for APUs starting with renoir, there is already documentation on how to get the telemetry data from the CPU. You can query the CPU data via the same interface the GPU driver uses (see the metrics table):
This kinda reminds of a meme;
Me: Damn, he explained everything perfectly, I need to apologize.
Inner Me: Ask him what he "means"...
So, anyway, I do owe you an apology, I guess I have been having some of the same experiences as other people who were upset about it and reading and trying to come up with solutions and getting upset myself.Comment
-
Yes, I will say that a lot of people here on acting entitled. AMD has better open-source Linux support than so many other companies. They could just provide binary blobs to hardware vendors and say sorry to all open-source users. Are they perfect? No. They have a long way to go, but as some employees here said - it takes a VERY long time for a large corporation to start spinning things back up after massive lay-offs. They do not want to over extend themselves too quickly.
And as others mentioned, temperature and power are really irrelvant to 99% of users. The hardware will manage itself. It'll control fans, throttle clock speeds, and shutdown if the temperature gets too high. All without user intervention. Just like how many modern cars don't have oil pressure, temperature or battery gauges. Just a warning light. It really just doesn't matter for most users.
Servers and other enterprise systems have external hardware management interfaces that they can use monitor and manage the systems.
I'm sure AMD will get it supported eventually, but it's not that critical right now.Comment
-
Comment