Please forgive my ignorance but I'm no expert in this area. Does this mean you'll be getting a different board? Going back to Windows? Or, something else? I don't understand.
It was my surmise-- and only a surmise-- and only after realizing that my earlier guesswork was wrong-- that Alain De Vos and I were probably in okay-shape, because our boards don't have fans anyway, and use passive cooling. Is that wrong?
I have other hardware that FreeBSD doesn't support. It's no big deal to me since I can always get supported hardware.
Finally, are some people coming to the conclusion here, that these same problems don't exist for Linux, but only for FreeBSD? Because I don't get where that's coming from either. When I compared the drm/dmesg output for Debian with the output from FreeBSD, earlier in this thread, it seemed to me that, since their message output was so similar, that they must have been using the same driver software. Or, as an old friend of mine likes to say, we all seem to be pissing out of the same quill. Am I wrong?
Vull,
Thank you for the reply. I'll respond to each point where I have knowledge.....
I will NOT be getting a different board. An AMD gpu is as mainstream as an NVIdia one. And NVidia has historically been obstructionistic and antagonistic towards anything OSS. They provide their proprietary driver instead of cooperating with OSS devs. My amdgpu works just fine under Windows and Linux. Although - Windows hasn't been on my system for ~ 1 year now. I run my Steam games under Linux - and they actually run better than in W10 natively. Not to mention a W10 update hosed my wife's system (she's a professor) and smoked 20+ years of her university work. Boy - was she ever pissed! I recovered it all with Linux, and we both ported to Linux to get away from MS's forced updates and other shenanigans that they pull on the average consumer.
If your GPU has passive cooling - then you are not in danger at all. My RX-480 will run hot if I run steam games...But when I use my python fan daemon - the highest temp I see instead of 180degF, is 130degF. It will also run hot under the new amdgpu driver just doing a desktop workload - as it initializes my fans to 0, instead of 900rpm like the older driver used to.
Be careful with the "supported" comment above. amdgpu
is indeed supported under FreeBSD - that's how I was running Mate and Xfce on my new FreeBSD 13 install on my spare SSD. Although mate was unusuably glitchy, xfce was smooth, smooth indeed. So FreeBSD supports amdgpu, but the version of the driver needed to operate under FreeBSD has a subset of the feature-set under Linux - obviously, or we would have a GPU temp and a PWM setting.
You are correct - my issue does not exist in Linux. I use this python daemon and it's all taken care of for me:
https://github.com/mcgillij/amdfan
And for clarification - it does not exist either for when I used to be on an NVidia GPU, but that was back in the 10.* days. Can't speak to NVidia now.
I am not about to call you wrong....no way....I have learned in my virtual travels the last few days, is that the amdgpu driver for FreeBSD - for it to work with the FreeBSD kernel, had to have some stuff "turned off". That is what I have read. So take that with a certain grain of salt as none of that came from a FreeBSD dev (that I am aware of), and that info does NOT come from personal knowledge - just a "he said" scenario.
However you have a good point. The technical driver version under Artix Linux (my current daily driver), and the version in FreeBSD - are indeed
identical. But that does NOT mean their internals are identical. The amdgpu driver had to be ported from Linux to FreeBSD. And the FreeBSD kernel and the Linux kernel - are two entirely different things, with different API's and such.....So I can imagine that the temp and fan info was turned off just to make the driver work under FreeBSD - with absolutely no malice intended whatsoever by the BSD dev's.
It's like this scenario when I was still working: When I was integrating a Carrier front end, with Carrier VAV boxes, yet with Trane RTU's via a JACE panel (Wind River Linux Based), I could not write to variables via the JACE panel that the Trane Rooftop Units didn't have, nor could I pass certain information to the Trane RTU's from the Carrier VAV's, that the Carrier VAV's wouldn't expose through public variables. I had to go with common denominators. While HVAC and BAS do not have much to do with FreeBSD nor Linux....It was a decision I had to make to integrate components from different manufacturers. I am pretty certain this type of thing is
exactly what the FreeBSD dev's are up against......
So - please don't blame anyone. Not AMD, not FreeBSD, not Linux, not Windows...It's just the way circumstances fell due to no fault on anyone's part.
I am confident that if I went to Microcenter, and laid down a few hundred dollars for an appropriately powered NVidia card, then used the NVidia proprietary drivers - none of this conversation would have actually been started. And GPU prices today with the chip shortage - are outrageous - so I am not going to waste money tearing out my perfectly functioning (and powerful enough) GPU in exchange for another brand - just to be able to run FreeBSD in a safe manner where I am not worried about slowly cooking my GPU. That would be ludicrous and a waste of resources IMHO.
So now you have some answers, and some more backstory to your post - and THANK YOU for your responses...
D