wrt to full fan speeds and GPU speed (or the lack of) with an RX 590
I wrote to Hans with adding a debug log while booting into WB with my RX 590 and this is what he answered: Quote:
- The driver doesn't directly control power management. Instead, it programs the System Management Controller (SMC) on the graphics card, and it's responsible for throttling everything from the fans to the GPU.
- Both the fans and the GPU speed are controlled by the SMC, and it's not so easy to update the code.
- [b]You could try checking online if anyone using the Linux AMDGPU driver is having the same problem as you.[/b90]
Means, the full speed fans are not "fixable" until there is a new version of the driver taking care of that SMC programming.
Same goes for the low speed of the GPU...my debug log shows that the card will be initialized at 300 MHz and won't go up, no matter what, so the actual speed it's able to pull off (for now) is similar to my RX 560...see above as to why it won't get "fixed" anytime soon either. Problem is, as always, lack of manpower, since Hans is working on the driver alone.
Also, i was the only one yet to provide feedback for an RX 590, but i don't think any more debug logs will help, but that is up to Hans, of course. I hope he'll find the time to work on that, would be cool to have such a beast supported.
I keep the RX 590 in for now, since, as i wrote, the speed is similar to the RX 560, so i don't lose anything.
My request would be, that anyone with a a Linux install, could test and maybe give feedback regarding the Linux AMDGPU driver having the same drawbacks, so Hans gets some more information
@Raziel The problem i have is not of "fan too fast", but instead "fan is too slow". I.e. even on high settings it always pretty slow on 2 of my RX cards, and because of it cards are pretty hot, and after 2-3 years of usage they start acts :(
Then only card which works fine since beginning is HD card, which has no power management and so FAN moving fast always, and card is not hot.
For me, it looks like our power managment or whatever is happens with drivers or amigaos i do not know, is doing something wrong, and the fans speed is _slow_ why should be faster. Because of which the cards is more hot than expected, and with time overhots and start acts : that happens with 2 of my RX cards on X5000. The HD one works fins still, and the difference that it have no power manamgnet for Fan, and speed of it always good, and card always cold.
Most of the RX series (RX 580, at least) have a so-called "Zero RPM" feature, where the fans suppose to turn on when a certain temperature is reached. Should be around 55°C - 60°C. Any temperature measured that is below such values should keep the fan silent/off.
In the original driver (on Windows) you can set a "fan or temperature curve" which will act on given temperatures. I don't think we have (or ever get) this feature, so the fact that your fans runs (at low speed nonetheless) on bootup, indicates that either your cards firmware doesn't feature that "Zero RPM" or Hans' driver implements something similar, but less drastic, which makes the fan spin (otoh maybe it's simply the default speed that the card will always fall back if anything else fails, who knows?).
I can say for myself that *every* original fan on *every* gfx card i plugged into my miggies had to go sooner or later, they were just too loud to handle. With my RX 590 i already ordered adapter cables to attach them to my case fan controller...right now it's a 747 taking off...24/7...unbearable.
For me, it looks like our power managment or whatever is happens with drivers or amigaos i do not know, is doing something wrong, and the fans speed is _slow_ why should be faster. Because of which the cards is more hot than expected, and with time overhots and start acts : that happens with 2 of my RX cards on X5000. The HD one works fins still, and the difference that it have no power manamgnet for Fan, and speed of it always good, and card always cold.
AFAIK, the driver reads the power management settings from tables on the graphics card's ROM, and loads them into the System Management Controller's (SMC's) tables.
A few possibilities if it's not doing what you expect: 1. The tables on the graphics card are wrong. This does happen, although less often these days. Drivers end up with "quirk tables" to work around these mistakes 2. The graphics card manufacturer prioritized low fan noise over card life (they'd very much like you to buy a new card every few years, or even every year; gamers are likely to want to upgrade, anyway) 3. The graphics card's ROM tables contain good settings, but the driver is misinterpreting them. AMD seem to change the formats regularly, so that's very possible, especially if the card is newer than the powerplay code 4. The ROM tables are read correctly, but something goes wrong when programming the SMC
Unfortunately, I don't think I can update the powerplay code independently of the rest of the driver. They've done a lot of internal refactoring of the driver code, so updating the driver core is a major pain in the butt.
Unfortunately, I don't think I can update the powerplay code independently of the rest of the driver. They've done a lot of internal refactoring of the driver code, so updating the driver core is a major pain in the butt.
But is is possible, isn't it? Can I hope for a RX 590 support?
But is is possible, isn't it? Can I hope for a RX 590 support?
Of course, but don't expect it to happen any time soon.
@derfs Quote:
Just to add for No. 2, hardware problem is also a possible issue if the main temp sensor is not working correctly and giving bad values.
Yes, that's possible too. The Radeon X1300 I bought and used early on had a problem with one of its RAM chips. It just so happened that this chip lined up with the alpha channel in 32-bit ARGB bitmaps, so it wasn't immediately obvious. It showed up with 8-bit and 16-bit modes as vertical lines. So yes, a bad sensor or other hardware is also possible.
@Hans At the risk of making myself unpopular or annoying, can we hope that the soft reset will work sometime again? For me, it is a defenetive part of the AmigaOS.
At the risk of making myself unpopular or annoying, can we hope that the soft reset will work sometime again? For me, it is a defenetive part of the AmigaOS.
Sorry, but no. I've spent far too much time & energy trying to get soft-reset to work already.
I don't see soft-reset as a definitive part of AmigaOS. It wasn't part of the original 68K AmigaOS. They only really became a thing with OS 4, because full reboots take so long.
My (unpopular) opinion, is that we should work on improving cold reboots. Part of the problem is the firmware (i.e, UBoot/CFE), but I think there's room for improvement with AmigaOS' boot process.
I don't see soft-reset as a definitive part of AmigaOS. It wasn't part of the original 68K AmigaOS. They only really became a thing with OS 4, because full reboots take so long.
OT, but that's wrong. On the original Amiga (later called Amiga 1000) a fast reboot just reboots the OS, but when doing a cold reboot, IIRC pressing and holding crtl-amiga-amiga for at least 5 seconds, it wipes everything and you fist have to reinsert and load the kickstart floppy disk before you can boot the Workbench floppy disk (or a game floppy disk) again. It was the same on some early versions of the A3000 with super kickstart loaded from either a floppy disk or a HD partition (file DEVS:kickstart), the ROM had a special kickstart version 1.4 (256 KB) only used for booting the super kickstart (512 KB, AmigaOS 2.x). AmigaOS 3.9: Some of the OS parts, incl. Exec updates, are installed by SetPatch and survive a fast reboot, but on a cold reboot they have to be reloaded/restarted.
But unfortunately the Early Startup Menu doesn't work so also anymore.
I've also advocated for making the Early Startup Menu work without needing a reboot. That was met with pretty fierce resistance.
@joerg
I didn't know some early Amiga versions had a soft reboot, but I'm well aware of SetPatch's behaviour with OS3.5/3.9. I don't think SetPatch needing to reboot the machine to patch the ROM is a feature,** but simply the way it had to work.
Hans
** At least, not one worth advertising beyond warning users that this is what their machines are doing.
...for me, it does not matter what OS3 does. Warm Start worked for years in OS4 and currently not. So people (myself too) work with older drivers to get warm start. And with this, Software or features which needs newer drivers may not work and cause new problems.
My X1000 needs 30 seconds only to heck X1000 hardware and shows logos, also before OS4 is booting, there is much time lost. It is a chain of problems.
For me, cutting a needed Feature is a no go and also sell a driver without a hint that some things doesn't work.
Many software are hobby based and not well optimized and crashes sometimes. For me some emulation stuff, also Arteffect, other gfx software, email. Also while building themes, i need much restarts. And for game testings too. I will never go with a system without a fast boot. Which is in current state of Hardware, OS and software ... the soft-reset ;)
Which could be solved by enabling it to also work with a cold reboot (assuming that the reset doesn't forcibly wipe the RAM).
@imagodespira Quote:
My X1000 needs 30 seconds only to heck X1000 hardware and shows logos, also before OS4 is booting, there is much time lost. It is a chain of problems.
Which is why I've been advocating doing something about the cold boot time...
I have to perform reboots between every driver test too, so I'm well aware of how much time it takes up.
Quote:
For me, cutting a needed Feature is a no go and also sell a driver without a hint that some things doesn't work.
Nobody "cut" any feature. After sinking countless hours trying to get even one more b****y card to soft-reboot, I simply cannot get it to work reliably. Newer drivers are even less likely to be able to soft reboot because we're supporting more and more of the GPU's hardware. The UVD and KCQ modules are particularly bad at locking up during a soft reset.
At some point it's time to accept that it's not practical, and that spending ever more engineering effort trying to hold on is incredibly wasteful. Time would be better spent fixing the slow cold boot process instead.
Years ago I suggested trying the techniques Google used to speed up booting of the Chromebook. That suggestion was instantly dismissed. If I could, I'd take on the task myself, but I have too much on my plate already.
EDIT: Oh, and how about putting some effort into making the OS less fragile and crash prone? That's the other reason people want fast reboots.
You're not the only one with a non-popular opinion
We all know the old joke about Windows: "32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition."
But at least Windows has seen so many rewrites and API changes to become the 21st century OS as it is today.
In Amiga land, everything has te remain the same as it was 30 years ago. While expecting seemles integration of 21 century technology. (The "only amiga makes it possible" mantra)
Hence all the stability issues: - No memory protection - Old code needs to run in the AmigaOS4 environment without sandboxing (because "not the amiga way" or something) - 2 GB limitation, because the amiga way is to use the upper bit for somethng else (2GB ought to be enough for everybody :-p ) - permit()/forbid() debacle which seriously slows down multicore development - No development leadership -> No documentations how everything should be done "properly" -> Everybody hacks their own way because we are supposed to be smart and creative. - And so on
Every serious componany does a reality check once in a while. And evaluate if it's time to let go of the past and make a step into the future.
Our community is more concerned about who owns what. And who is entitled to develop for AmigaOS4.
The AmigaOS4 way is "A 21st century hack and patch job of a PowerPC port of a C code reimplementation of a 32bit 80's OS originally coded in assembly for a 16bit processor which is developed with 2 bits years between updates by 1 bit companies who are more pre-occupied with lawsuits over who owns the corpse than actually paying developers to get the work done."
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
