Google Engineers Have Been Working On An AMD SB-TSI Temperature Driver

[M@GOid]

Why? As long as default cooling curve in BIOS/UEFI is fine, then I really don't need to know my CPU's temperature,... In the end, my laptop/desktop is just a tool, and I want it to work out-of-the-box, and therefore invest my time in better things, than tinkering with cooling curve,...

You may not want to look at it, but others might, especially on systems accessed remotely, like a server or some embedded device. Also, on desktop/laptop it is useful to monitor it while on some task to confirm that the cooling solution is operating adequately, especially if said system had a few years under their belt. Laptops for example are prone to accumulate dust/somecrap on the heatsink, making it overheat and slowdown or even shutdown. A look in the BIOS might not reveal this as a problem because it isn't under load.

[M@GOid]

@M@GOid I don't know if it surprises you, but Intel is doing much of the software grunt work (Kernel, toolchain support etc.) in the X86 ecosystem which AMD and other X86 vendors profit from to a large degree. That is nothing new though. Also AMD contracts some of the architecture specific work out to others (e.g. compiler tuning is done by SUSE for them for GCC). And I see nothing wrong with that approach bringing third parties ito the table, after all AMD is a much smaller company. With compelling products others do have an incentive to invest into AMD's product stack which furthers their attractiveness even more. AMD had to close their open source technology center which was responsible for the early bring up of new platforms. With more cash at hand I expect them to invest more into their ecosystem as there are still some blind spots which need their attention (e.g. Glibc called out for help from them).

Looking at AMD's today success is easy to forget they were letting go employees just a few years ago, because they were almost bankrupt. But those times are over, and these little things are important for their customers, so I hope they can pay more attention to it in the near future.

As for Intel, while I declare myself as a AMD fanboy, they still get my respect (and money, as I have 2 laptops and a desktop running on Intel) for all development they do on Linux.

[creative]

That is one impressive looking board!



Kind of a side subject.

As of right now on my X570-P I see no thermals for PCH even in UEFI. Guessing Asus will eventually be rolling out some UEFI/BIOS updates for this maybe later. Right now all I am able to see is PCH fan rpm.

Still.. So far so good for the CPU though, have the tdie sensor renamed in psensor. Was able to get thermals to idle 26c-28c on a cool day and with low latency high priority jackdbus enabled idle is usually 33c-36c+ idle with higher process priority+boost cycling up to around 43c and back down. R5 3600, Cryorig M9A (with aggressive lower noise fan curve) will be migrating to a R1 Universal though for a 12core. Rarely break 70c now.

[Space Heater]

Also AMD contracts some of the architecture specific work out to others (e.g. compiler tuning is done by SUSE for them for GCC). And I see nothing wrong with that approach bringing third parties ito the table, after all AMD is a much smaller company.

If it is just a matter of AMD not having enough resources, why are they actively hiding temperature offsets from open source developers?
I understand not having staff, but that doesn't excuse their behavior of requiring an NDA to even see the information.

[ms178]

If it is just a matter of AMD not having enough resources, why are they actively hiding temperature offsets from open source developers?
I understand not having staff, but that doesn't excuse their behavior of requiring an NDA to even see the information.

The reasoning behind this decision is a question only AMD can answer and I agree with you that this is not optimal from our perspective. Maybe it is due to third party IP?!

[ms178]

Great news concerning the Glibc engagement from AMD for AVX2 ifunc on Zen CPUs: https://sourceware.org/pipermail/lib...ch/111930.html

That would deserve its own news article on the front page.

[NotMine999]

If it is just a matter of AMD not having enough resources, why are they actively hiding temperature offsets from open source developers?
I understand not having staff, but that doesn't excuse their behavior of requiring an NDA to even see the information.

I disagree with your conclusion that AMD is "hiding it". The link you provide does not prove or disprove anything relative to your conclusion. Heck, some "developers" out there flat out will not EVER sign any NDA under any circumstances with anyone else; I consider that attitude to be short-sighted.

Placing information under NDA, and I have signed a few in the past, can be due to any number of reasons:

• The information might contain proprietary knowledge that has current and/or ongoing competitive value to other manufacturers in the same business.
• AMD might simply want to know who is expressing an interest in using their information and in what ways it will be used.
• AMD might not be ready to disclose the knowledge, for any number of reasons, as "open source" or "public domain" or whatever.
• AMD might not have the internal resources to support inquires from every "developer" that is out there, and we know AMD is slowing building up staff.

And let's all be honest here. Only AMD knows why they are imposing a NDA on this information, and they are under no obligation to explain their internal decisions to us, even if we sign a NDA.

[Space Heater]

I disagree with your conclusion that AMD is "hiding it".

The link I provided establishes the following:

1. AMD is not contributing these changes nor are they providing documentation to open source developers.
2. The current temperature reading support is a result of using leaks and reverse engineering
3. AMD had some of this information in their GPU driver and has since removed it with no explanation, and the only impact this has is to make it more difficult to provide temperature reading support for their CPUs.

The link you provide does not prove or disprove anything relative to your conclusion

That they are taking active measures to make it more difficult to upstream temperature support?

Please explain how it does not suggest that, you even seem to agree later in your post by providing a list of reasons why AMD does not want to share this information:

• The information might contain proprietary knowledge that has current and/or ongoing competitive value to other manufacturers in the same business.
• AMD might simply want to know who is expressing an interest in using their information and in what ways it will be used.
• AMD might not be ready to disclose the knowledge, for any number of reasons, as "open source" or "public domain" or whatever.
• AMD might not have the internal resources to support inquires from every "developer" that is out there, and we know AMD is slowing building up staff

What I am saying is that AMD is actively making it harder to have temperature support in upstream Linux, and that simply being short on money and staff does not explain all of their behavior.

Only AMD knows why they are imposing a NDA on this information, and they are under no obligation to explain their internal decisions to us, even if we sign a NDA

I honestly don't care what reason they have, nor did I ever suggest that they need to tell us why they are being hostile towards upstreaming temperature support.

The point is that they are behaving poorly compared to other processor vendors in this area.

It's not really clear what your post is trying to say or what it is even arguing against. This seems to occur whenever someone makes even a slight criticism of AMD.

[agd5f]

No one at AMD is actively trying to prevent development of the temp driver. Windows is a bigger market. All of the documentation is under NDA because it's generally released prior to product launch and it was originally written to support windows. It's a lot of effort to scrub all of the documentation of all of the NDA and confidential watermarks, etc. and get legal to sign off on it. As to the the SMU interfaces exposed in the GPU driver, they change with each generation. There was no active removal to thwart people trying to work on the thermal sensors for the CPU.

[Space Heater]

No one at AMD is actively trying to prevent development of the temp driver.

I am certain the AMD developers that work on Linux support are not the people who are making this difficult.

All of the documentation is under NDA because it's generally released prior to product launch and it was originally written to support windows. It's a lot of effort to scrub all of the documentation of all of the NDA and confidential watermarks, etc. and get legal to sign off on it.

It sounds like AMD legal is the roadblock once again, same reason Navi support was delayed for months.