• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.
  • The forums have been upgraded with support for dark mode. By default it will follow the setting on your system/browser. You may override it by scrolling to the end of the page and clicking the gears icon.

PSA: AMD's Graphics Driver will Eat One CPU Core when No Radeon Installed

I recall a similar performance issue I diagnosed for a client back in 2014ish with a dual core i3 and GTX 750, with Nvidia Shadow Play eating up more than its share of CPU and memory performance because it was something that was hidden in the default driver package and enabled by default. I'm sure that wouldn't be an issue with today's many-core machines, but it really crippled that poor old dual-core.
 
God! The more I browse the internet the more I come to know that AMD software sucks.
1. Remember the WHQL certified NV driver that made Watch Dogs 2 instantly crash on start or even won't allow to start it?
2. The Chrome video playback problems with WHQL NV driveres not too long ago?
3. The RTX 3000 series drivers at the beginning?
 
Nice find W1zz. Did you submit bug through AMD bug reporter ;)

edit - dual core - how old is that rig? :)

and for rest of the thread - I have seen bad/poor/lazy coding from everywhere.

Doesn't come down to where, so much as
-time
-money
-qa/qc/review/
-experience/good habits

Edit 2 - I actually barely passed C+ programming class, that's ok since I'm mechanical engineer ;)

Maybe the compiler or something should be stricter and spit the code back if its 'lazy' :)
 
Last edited:
Reading the news article in here about this bug, and the way it is written, made me to remember a conversation I had with a friend of mine a couple of days ago about some performance numbers in TechPowerUps' reviews. He got a second hand Vega56 and when checking it in Odyssey, he gets way higher frame rates than those reported here. And he is using a simple Ryzen 2600, not an overclocked 5GHz Intel CPU.

I don't know if it relevant. Just remembered that conversation.
 
you exposed AMD's way of punishing those who leave them. :laugh:
 
This one simple trick to fix this issue: Don't install drivers and bundled software on a system for a piece of hardware not installed.

The issue is more that this is a super rookie mistake.

It makes you ask how much else is crap in the driver...
 
Nice investigation! Which tool did you use to convert the assembly to a bit more readable C?
 
It is a well known issue! AMD is one of the companies that secretly (!) creates an entry in Windows Task Scheduler to load "RadeonSettings.exe" every time a Windows OS starts. It actually violates your privacy.
OK, no, that's BS. Let me show you what's in my task scheduler:
20201204-170839.png

Have Adobe software? They create at least one entry for software activation and update.
CCleaner? Update and Skip UAC tasks.
Google Chrome, Earth or anything else from the big G? Two update tasks (I imagine that one of them is also for skipping UAC)
Microsoft Edge? Same thingy, update tasks.
MSI Afterburner has its own and if you have the RivaTuner Stat server installed, then it will add the RTSS task,.
Onedrive? More tasks.
Then there is the "User feed sync" task, which frankly I don't know what is it for, and finally the AMD tasks.
I also have BlueStacks around, but that's definitely niche.
And those are the tasks that no-one bothered to "organize", otherwise you better start considering every task hidden in each folder:
20201204-173128.png


Conclusion: every one and their mother use the task scheduler, it's not a secret, and in fact is a service that is required to run a bunch of system tasks. And privacy? Why the hell are you installing the Radeon Software bundle, then, if you don't trust them to agree to you not joining their User Experience Program or not sending your system specs for the upgrade advisor feature? Hell, why would you use Windows for that matter, considering it's a privacy-advocate's nightmare?
20201204-172319.png
 
and when checking it in Odyssey, he gets way higher frame rates than those reported here
FPS depends a lot on the game location, or did he play the benchmark? I use actual gameplay. Cities vs outside huge difference. AC:O is also difficult to repro run-to-run because dynamic weather and other random events

Nice investigation! Which tool did you use to convert the assembly to a bit more readable C?
No tool needed, the assembly is fairly obvious. Typed out in UltraEdit for the syntax coloring. What do you use? Always happy to learn about software to make my life easier
 
Maybe the compiler or something should be stricter and spit the code back if its 'lazy' :)

Compiler from ANY brand wont detect lazy code, it will only call out syntax error or null reference at best, as far as I know. Lazy code in lower level language hurts performance a lot more to be honest.

On the other hand, they could have hired another donzen of cheap intern to debug or look through the code.

This is just sloppy implementation, there is no other way to cut it.
 
absolutely, yes. but if it happens to me, it can happen to others, too i would like to think

It can, I've experienced many oddities having to do with drivers.
 
Compiler from ANY brand wont detect lazy code, it will only call out syntax error or null reference at best, as far as I know. Lazy code in lower level language hurts performance a lot more to be honest.

On the other hand, they could have hired another donzen of cheap intern to debug or look through the code.

This is just sloppy implementation, there is no other way to cut it.
Technically, once you've uninstalled the hardware, it's unclear whose responsibility it is to clean unused software. Most of the time, it will fall on admins or the users themselves. Even our very advanced operating systems these days cannot prune crud for us.
 
I would rate this issue as pretty minor myself, but good find nonetheless and hopefully AMD's software gets better as a result.
 

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.
While I do commend you for taking the time to debug this, I have to point out that the real problem is whatever is causing the driver to end up in an invalid state. The problem you have spotted is really only the symptom, not the cause. While dealing with system calls may need some handling, it's much more important to catch the invalid state before this system call, probably with an assertion, so they would actually catch this bug during QA (assuming they do QA before shipping).
Just making the code more "forgiving" would just suppress the underlying problem, and depending on the surrounding code it may sometimes actually not be a good idea. I've seen many developers chase "endless" streams of bugs because they just suppress them.

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.
Respectfully disagree.
While 100-line textbook examples are easy to manage, working on synchronization and threading in larger code bases is an expert level skill. Synchronization is also very tough to validate, and bugs may be hard to reproduce, especially when dealing with issues on the scale of microseconds or nanoseconds.
I'm not surprised these drivers are full of "glaring mistakes". In real life code is often stitched together under tight deadlines, bugs are swept underneath the rug, and workarounds are favored over proper rewrites, often by management who thinks "it can be fixed after the deadline". I've witnessed some major screw-ups, such as relying on a completely defective mutex implementation in some military stuff for >20 years… I just hope my loved ones are nowhere near when s*** hits the fan…

Modern software development techniques avoid these mistakes by code reviews—one or multiple colleagues read your source code and point out potential issues.
They certainly should, but in reality it's fairly uncommon for someone doing QA to read every line and test every possible outcome.
But I believe critical code should strive for this, such as kernels, drivers, firmware, etc.

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.
Unit tests should be a part of many project's toolchains, but only a small part, as unit tests only can cover a tiny portion of potential problems. Unit tests tests a unit (function, class etc.) in a vacuum, problems such as the one described above are outside the scope of a unit test.
But don't mention code coverage, that gives me chills. A completely useless metric which misleads developers into thinking code is actually tested :)

-----

I still enjoyed the article though Wizz, tech websites needs more of this. Even deeper stuff if possible; the deeper the better :)
Have a nice evening.

Maybe the compiler or something should be stricter and spit the code back if its 'lazy' :)
:P
If we ever get compilers able to detect stupidity, we would probably not need programmers anymore.
 
Low quality post by Dave65
1. Remember the WHQL certified NV driver that made Watch Dogs 2 instantly crash on start or even won't allow to start it?
2. The Chrome video playback problems with WHQL NV driveres not too long ago?
3. The RTX 3000 series drivers at the beginning?

Nvidia fan boys always forget. I have had no problems with mine, except once when 5700xt came out and I switched from Nvidia.
 
Or ...

Just remove the driver before changing the GPU ?

Right? like isnt running DDU twice in safe mode standard when installing a new gpu? I mean yeah its weird behavior but I mean even if it did nothing its still just bloatware when it goes unused....just weird to leave it there.
Heck I would be afraid it would conflict with the new hardware anyway....
 
Forgetting to uninstall a whole driver suite after a hardware change, lead to problems?
Who would have thought?!?!
I find that attitude a bit odd.
Drivers and utility software should behave properly and not cause issues even if they remain in the system.
It's consumer software and users may not even be aware they need to uninstall after changing the graphics card. Why would it be expected of them to know that?
This is common sense for users on TPU but not for an average joe.

In real life code is often stitched together under tight deadlines, bugs are swept underneath the rug, and workarounds are favored over proper rewrites, often by management who thinks "it can be fixed after the deadline".
So true, happens all the time. Because of deadlines, things are made to work just "for now", for the upcoming presentation or for a particular implementation, and a "proper" fix is saved for later - when there's time. Most often that time never comes because there are already other projects with new deadlines. Those patchwork solutions then remain in place until they rear their ugly head again, causing new problems.

It's just that one could expect (naively I guess) that a company of this size, with such a big consumer base, would take extra measures and utmost care with something as critical as a driver suite.
 
Thanks for posting this. Some of the behavior with Radeon Software is mind boggling. There's a lot more to uncover here and I hope you do some more digging. Making this more known will help put pressure to get it addressed.

The same loop is hit if the Host Services processes don't load, such as when you rename the files. And this isn't old/legacy code either, it started just a month or two ago. The Radeon Host Services load when you open Radeon Settings or on login from a couple hidden Scheduled Tasks. StartCN will load RadeonSettings and the Host Services and StartDVR will load the Host Services. Disabling these and never opening Radeon Setting will prevent these processes from loading.

Another annoying example is with their OpenVR Driver (AMD WVR64). It installs even if you don't have a VR device and is hidden from Programs and Features. When it's installed, it tries to load two configuration files every second. You can see it with Process Monitor. I can't imagine a non-SSD user would appreciate that.
 
Interesting, I remember a few years ago I found a defect with Nvidia drivers using all my I/O bandwidth for no explainable reason.
 
Cost saving is most likely the answer. AMD was short on cash before Zen. It works well for them to outsource driver R&D to country with way lower average wage and good educated workforce (India and China. Taiwan, SK or Japan are most likely just as expensive as here in US)

FWIW my cousins brother in law was given a cushy AMD job making drivers in Canada in the 2000's, but I assume they have restructured it a dozen times since then.
 
absolutely, yes. but if it happens to me, it can happen to others, too i would like to think

Hopefully it doesn't happen in your testing rigs. That would be awful. AMD makes a cleanup utility incase you didnt know.

AMD Cleanup Utility

Overview
The AMD Cleanup Utility is designed to thoroughly remove any previously installed AMD driver files, registries, and driver store from systems running Microsoft Windows® 7 and later. The cleanup process includes removing AMD display and audio drivers as well as AMD software components but does not remove AMD chipset driver components such as GPIO, SATA, USB, etc.
 
absolutely, yes. but if it happens to me, it can happen to others, too i would like to think


not at all, consider what they pulled off this year alone. beat intel, matched nvidia, beat nvidia energy efficiency. these are tremendous achievements
Possibly a little dramatic IMHO.
 
Good find, but what are we expecting from a "driver" that has integrated chromium, phone connectivity, streaming app, animated GIFs writer and other steaming-pile-of-horseshit-bloat??
 
Good find, but what are we expecting from a "driver" that has integrated chromium, phone connectivity, streaming app, animated GIFs writer and other steaming-pile-of-horseshit-bloat??
Well, someone probably uses that stuff. I myself have used the animated GIF thing.
 
Back
Top