Friday, December 4th 2020
PSA: AMD's Graphics Driver will Eat One CPU Core when No Radeon Installed
While I was messing around with an older SSD test system (not benchmarking anything) I wondered why the machine's performance was SO sluggish with the NVIDIA card I just installed. Windows startup, desktop, Internet, everything in Windows would just be incredibly slow. This is an old dual-core machine, but it ran perfectly fine with the AMD Radeon card I used before.
At first I blamed NVIDIA, but when I opened Task Manager I noticed one of my cores sitting at 100%—that can't be right.
Digging a bit further into this, it looks like RadeonSettings.exe is using one processor core at maximum 100% CPU load. Ugh, but there is no AMD graphics card installed right now.
Once that process was terminated manually (right click, select "End task"), performance was restored to expected levels and CPU load was normal again. This confirms that the AMD driver is the reason for the high CPU load. Ideally, before changing graphics card, you should uninstall the current graphics card driver, change hardware, then install the new driver, in that order. But for a quick test that's not what most people do, and others are simply not aware of the fact that a thing called "graphics card driver" exists, and what it does. Windows is smart enough to not load any drivers for devices that aren't present physically.
Looks like AMD is doing things differently and just pre-loads Radeon Settings in the background every time your system is booted and a user logs in, no matter if AMD graphics hardware is installed or not. It would be trivial to add a check "If no AMD hardware found, then exit immediately", but ok. Also, do we really need six entries in Task Scheduler?
I got curious and wondered how it is possible in the first place that an utility software like the Radeon Settings control panel uses 100% CPU load constantly—something that might happen when a mining virus gets installed, to use your electricity to mine cryptocurrency, without you knowing. By the way, all this was verified to be happening on Radeon 20.11.2 WHQL driver, 20.11.3 Beta and the press driver for an upcoming Radeon review.
Unless you're a computer geek you'll probably want to skip over the following paragraphs, I still found the details interesting enough to share with you.
I attached my debugger, looked for the thread that's causing all the CPU load and found this:
Hard to read, translated it into C code it might make more sense:
If you're a programmer you'd have /facepalm'd by now, let me explain. In a multi-threaded program, Events are often used to synchronize concurrently running threads. Events are a core feature of the Windows operating system, once created, they can be set to "signaled", which will notify every other piece of code that is watching the status of this event—instantly and even across process boundaries. In this case the Radeon Settings program will wait for an event called "DVRReadyEvent" to get created, before it continues with initialization. This event gets created by a separate, independent, driver component, that's supposed to get loaded on startup, too, but apparently never does. The Task Scheduler entries in the screenshot above do show "StartDVR". The naming suggests it's related to the ReLive recording feature that lets you capture and stream gameplay. I guess that part of the driver does indeed check if Radeon hardware is present, and will not start otherwise. Since Windows has no WaitForEventToGetCreated() function, the usual approach is to try to open the event until it can be opened, at which point you know that it does exist.
You're probably asking now, "what if the event never gets created?" Exactly, your program will be hung, forever, caught in an infinite loop. The correct way to implement this code is to either set a time limit for how long the loop should run, or count the number of runs and give up after 100, 1000, 1 million, you pick a number—but it's important to set a reasonable limit.
A more subtle effect of this kind of busy waiting is that it will run as fast as the processor can, loading one core to 100%. While that might be desirable if you have to be able to react VERY quickly to something, there's no reason to do that here. The typical approach is to add a short bit of delay inside the loop, which tells the operating system and processor "hey, I'm waiting on something and don't need CPU time, you may run another application now or reduce power". Modern processors will adjust their frequency when lightly loaded, and even power down cores completely, to conserve energy and reduce heat output. Even a delay of one millisecond will make a huge difference here.
This is especially important during system startup, where a lot of things are happening at the same time, that need processor time to complete—it's why you feel you're waiting forever for your desktop to become usable when you start the computer. With Radeon Settings taking over one core completely, there's obviously less performance left for other startup programs to complete.
I did some quick and dirty performance testing in actual gameplay on a 8-core/16-thread CPU and found a small FPS loss, especially in CPU limited scenarios, around 1%, in the order of 150 FPS vs 151 FPS. This confirms that this can be an issue on modern systems, too, even though just 5% of CPU power is lost (one core out of 16). The differences will be minimal though, and it's unlikely you'll subjectively notice the difference.
Waiting on synchronization signals is very basic programming skills, most midterm students would be able to implement it correctly. That's why I'm so surprised to see such low quality code in a graphics driver component that get installed on hundreds of millions of computers. Modern software development techniques avoid these mistakes by code reviews—one or multiple colleagues read your source code and point out potential issues. There's also "unit testing", which requires developers to write testing code that's separate from the main code. These unit tests can then be executed automatically to measure "code coverage"—how many percent of the program code are verified to be correct through the use of unit tests. Let's just hope AMD fixes this bug, it should be trivial.
If you are affected by this issue, just uninstall the AMD driver from Windows Settings - Apps and Features. If that doesn't work, use DDU. It's not a big deal anyway, what's most important is that you are aware, in case your system feels sluggish after a graphics hardware change.
Once that process was terminated manually (right click, select "End task"), performance was restored to expected levels and CPU load was normal again. This confirms that the AMD driver is the reason for the high CPU load. Ideally, before changing graphics card, you should uninstall the current graphics card driver, change hardware, then install the new driver, in that order. But for a quick test that's not what most people do, and others are simply not aware of the fact that a thing called "graphics card driver" exists, and what it does. Windows is smart enough to not load any drivers for devices that aren't present physically.
I got curious and wondered how it is possible in the first place that an utility software like the Radeon Settings control panel uses 100% CPU load constantly—something that might happen when a mining virus gets installed, to use your electricity to mine cryptocurrency, without you knowing. By the way, all this was verified to be happening on Radeon 20.11.2 WHQL driver, 20.11.3 Beta and the press driver for an upcoming Radeon review.
Unless you're a computer geek you'll probably want to skip over the following paragraphs, I still found the details interesting enough to share with you.
I attached my debugger, looked for the thread that's causing all the CPU load and found this:
You're probably asking now, "what if the event never gets created?" Exactly, your program will be hung, forever, caught in an infinite loop. The correct way to implement this code is to either set a time limit for how long the loop should run, or count the number of runs and give up after 100, 1000, 1 million, you pick a number—but it's important to set a reasonable limit.
A more subtle effect of this kind of busy waiting is that it will run as fast as the processor can, loading one core to 100%. While that might be desirable if you have to be able to react VERY quickly to something, there's no reason to do that here. The typical approach is to add a short bit of delay inside the loop, which tells the operating system and processor "hey, I'm waiting on something and don't need CPU time, you may run another application now or reduce power". Modern processors will adjust their frequency when lightly loaded, and even power down cores completely, to conserve energy and reduce heat output. Even a delay of one millisecond will make a huge difference here.
This is especially important during system startup, where a lot of things are happening at the same time, that need processor time to complete—it's why you feel you're waiting forever for your desktop to become usable when you start the computer. With Radeon Settings taking over one core completely, there's obviously less performance left for other startup programs to complete.
I did some quick and dirty performance testing in actual gameplay on a 8-core/16-thread CPU and found a small FPS loss, especially in CPU limited scenarios, around 1%, in the order of 150 FPS vs 151 FPS. This confirms that this can be an issue on modern systems, too, even though just 5% of CPU power is lost (one core out of 16). The differences will be minimal though, and it's unlikely you'll subjectively notice the difference.
Waiting on synchronization signals is very basic programming skills, most midterm students would be able to implement it correctly. That's why I'm so surprised to see such low quality code in a graphics driver component that get installed on hundreds of millions of computers. Modern software development techniques avoid these mistakes by code reviews—one or multiple colleagues read your source code and point out potential issues. There's also "unit testing", which requires developers to write testing code that's separate from the main code. These unit tests can then be executed automatically to measure "code coverage"—how many percent of the program code are verified to be correct through the use of unit tests. Let's just hope AMD fixes this bug, it should be trivial.
If you are affected by this issue, just uninstall the AMD driver from Windows Settings - Apps and Features. If that doesn't work, use DDU. It's not a big deal anyway, what's most important is that you are aware, in case your system feels sluggish after a graphics hardware change.
277 Comments on PSA: AMD's Graphics Driver will Eat One CPU Core when No Radeon Installed
The shoe fits on the error foot, if not the severity one.
after quick googling i found this
community.amd.com/t5/drivers-software/amd-relive-host-application-high-cpu-usage/td-p/92347
back in the day some pointed at this problem only coming up when intel igpu is present. Some needed to delete the DVR exe. in C:/program files/AMD/C Next/Cnext
Some even couldn´t install HWinfo after that problem occured.
i my head was until today my own reminder: Dont install ReLive ever.
I hope you reported the bug ...That is fine in theory, but what if debounced listener has problems catching the signals? Then this process might take even longer or be stuck in an infinite loop forever even if you have a Radeon GPU. Just a guess ... :)
You're really doing a bang-up job with this "unbiased" thing.
Next are you going to write a hitpiece about ARM and Android, while saying that iOS devices are absolutely not locked down? :P
when changing gpu and manufacturer the old driver usually is uninstalled(by user-edited for any misunderstanding...) but it may happen to remain...
this issue may affect mostly the reviewers if they just swap the cards in the test system
Of course that would be horror cenario for W1zzard who is testing lot of cards and uninstalling drivers after every GPU change will be terrible. :banghead:
I did the same when I went from Radeon VII to 6800XT although on the same drive version for both but looking at for example Wattman I see that 6800XT has completely different menu.
I am not sure if the Radeon Software would do proper setting if I would have just switched cards without uninstalling driver first though installing back same version again. :confused:
In any case I did not wanted to take the risk of having unexplained problems. :laugh:
This is article is far more advanced than most other tech sites would publish, even the renowned Anandtech's "in-depth" articles usually only scratches the surface, and only sound technical to non-engineers.You must be kidding, right?
Do you really expect every user to know how to use DDU when switching GPUs? Then at least shouldn't this be shown as a big disclaimer before buying such products?In 99.999% of cases such bugs are accidents, negligence, incompetence, etc.
I seriously hope no one in here thinks such bugs are intentional.What? :eek:
It's not uncommon for developers to have multiple GPUs from different makers.
If a system is "broken" because a driver is not uninstalled, then the driver is broken, end of discussion.
we don't know if this behavior also appear on system with amd apu's mixed with dedicated nv gpu so we need feedback from people in this situation... not valid as hardware is always there so no conflict...Perhaps you're biased and reaching for examples...I totally have a few times, it's called onboard graphics. i've also done it before testing GPU's, VBIOS flashing, etc etc. It's not common for a home user, but its also commonly problem free
Sad but true - bad press is often the only way to force corporations to fix their products. When contacted directly by user, they'll either not respond, straight up deny existence of a problem, or forward to customer support, with endless loop of "did you try to turn it off and on" and "did you try uninstalling and installing"...
And it doesn't matter if that's a bug affecting performance, or a security vulnerability.
There's no such thing as being nice. Bug? Make it loud. Vulnerability? Send emails to appropriate places, and file a CVE with 90 days disclosure deadline."is"? Driver package doesn't uninstall itself automagically. The driver itself (.sys file) isn't loaded by OS when there's no GPU, but the settings app and services are still run in background.
I do compare them under the same conditions, using my own test scene. I played through the whole game to pick that scene, and I do claim my results will give you a more accurate representation than the benchmark of what to expect when you play the game. Obviously you can always pick a spot in any game that will give you different results than any other result. If you prefer to play the benchmark, so be it, look at other reviews. Don't you think my life would be MUCH easier if I just tested the benchmark, vs playing the same scene for hundreds of times? Another problem with nearly every integrated benchmark is that you are taking results off a cold card, which will boost much higher. For 30 seconds, and then performance drops. Ask your favorite reviewers about that.
Ultimately you'll have to trust me a little bit to do the right thing, if you don't, then you should absolutely not read my reviews.By default, Windows will not start anything in background for non-present devices. You actually have to do work (and not care about your non-customers) to launch something, separately from the OS logic
This is inexcusable for such a big company. The only reason is what we have always suspected: lack of talent is cheaper. Its how they have kept both AMD and RTG afloat with minimal expense.
Its a trend, not an occurrence. And AMD condones the shit quality code. Driver and microcode oopsies happen all the time. Fix forward seems to be the approach and overall strategy. It is for that reason also that such anomalies in code exists. The impossible was forced to possible with dirty tricks. If you roll back and fix, you dont need those.
www.linkedin.com/pulse/service-recovery-rolling-back-vs-forward-fixing-mohamed-el-geish