• 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

With all due respect, no commercial programmer should make a mistake like this ever.
That's an opinion. I appreciate your passions and expertise in this area. However I think you are being a little less than objective here.
It's actually less complicated than you think.
No it isn't. I've recently been dipping into ASM coding for the 65C02 CPU. That is 8-bit code in a total code package of less than 128kb. THAT is very complicated and we are way beyond all of the 8bit stuff with modern PC code.
 
Last edited:
Mhm yeah they also totally havent been making and hopefully nurturing a driver team since forever, right?

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.

I'm sure, you will be able to share with us, some personal stories about the talentless AMD employees and how they condone shitty quality work.
Driver oopsies happens with everyone. Many WHQL Nvidia drivers have Hotfix releases.
I don't know about microcode problems with AMD, what i do know is that, i had to update my Intel chipset firmware yet again, because of 20+ CVE's.
The amount of times i had to update IME firmware because of CVE's is mind-boggling.
 
Last edited:
Evidence of a mistake, yes. However, the problem that exists strikes me as one that is fairly complicated and not something that could have been anticipated as a potential issue. This was an honest mistake much like the ones Intel, NVidia, Apple, Google, Microsoft, Adobe, etc, etc have made. Computer code is extremely complicated. People really need to stop making mountains out of mole-hills.

This situation, simplified down(as best I can manage, @W1zzard feel free to correct me if I've misunderstood things), is a set of instructions intended to perform a function erroring out and failing to truncate the process it's attached to, getting caught in an infinite loop and as a result pegs the CPU it's thread is running on at full processing cycles. This unfortunately continues until the process is terminated by system or user command.

People offering negative comments really need take a step back and think about how complicated things really are and try a bit of understanding. This is an example of something slipping passed those in charge of testing & debugging. Little more.
Wizzard mentioned specifically already that in cases where a loop can get stuck executing infinitely, any seasoned programmer would have put in thresholds to terminate the abnormal behavior. The only way this would have been caught is with a code review. Testing would not have caught this, because the situation of not having the hardware installed with the software falls out of coverage scenarios. The fact that there were no attempts at any safeguards is puzzling and lends concern towards risky programming behavior, as evidenced by the plague of RDNA driver problems.
 
Last edited:
THAT is very complicated

From a code branching perspective and decompiling (or lack thereof) perspective it's actually less.

You're not the only one who has played with asm. I used to write and make eeprom replacement games for my NES. ;)

This thread sure went places over a edge case.
But hey, it's driving weekend traffic, plus we can shit on RTG drivers, so life's good.

...

you know what, never mind.
 
O look amds software team being utter shiet again
more news at 11

psa: to the non programmers when you see errors like this its indicative of a programmer not knowing what the fuck they are doing
no good programmer would make this mistake, It leaves one to wonder if they made this error..... What else did they fubar that may be causing unnecessary performance penalty's
 
I'm sure, you will be able to share with us, some personal stories about the talentless AMD employees and how they condone shitty quality work.
Driver oopsies happens with everyone. Many WHQL Nvidia drivers have Hotfix releases.
I don't know about microcode problems with AMD, what i do know is that, i had to update my Intel chipset firmware yet again, because of 20+ CVE's.
The amount of times i had to update IME firmware because of CVE's is mind-boggling.

Look what coding oopsies did to the 737 MAX :roll: . After a whole year AMD has managed to iron out the oopsies from their previous drivers, only to make new ones.
 
Look what coding oopsies did to the 737 MAX :roll: . After a whole year AMD has managed to iron out the oopsies from their previous drivers, only to make new ones.
Quite a leap you took there, from GPUs to 737 Max. Also are you saying that, Nvidia writes infallible code?

Alot programming gurus in this comment section, maybe you should apply for a job at AMD. Explain to them, how you're going to save them from themselves.
 
it's not rocket science maybe, except AMD developers aren't able to fix a very basic issue (you don't have the hardware, don't load the driver).
Not every user is aware of this problem. But AMD developers should be.

The driver isn't loading at all. Calling the settings application a hardware driver shows how knowledgeable you are about this so-called "issue". This is hyperbole at best, but realistically, it's another pathetic hitpiece against AMD that has no basis in fact or reason.

People keep making drama about this, but there's effectively no issue. Prattling on and beating a dead horse over nothing is just childish behavior. TPU should strive to be better than to devolve to such pettiness, in any event. This is making me really miss HardOCP.
 
I have Radeon GPU and it still puts one thread at 100% usage. Check following image. i.imgur.com/XEbMEW2.png

You can clearly see I can use Radeon settings just fine and it even picks up GPU but it still takes one thread for itself. I just DDU'ed system again and it didn't change anything. I have to kill Radeon Settings process every time I use it.

Might as well downgrade to like 19.something version, at least it was nice and stable and not bloated.
 
The driver isn't loading at all. Calling the settings application a hardware driver shows how knowledgeable you are about this so-called "issue". This is hyperbole at best, but realistically, it's another pathetic hitpiece against AMD that has no basis in fact or reason.

People keep making drama about this, but there's effectively no issue. Prattling on and beating a dead horse over nothing is just childish behavior. TPU should strive to be better than to devolve to such pettiness, in any event. This is making me really miss HardOCP.

I'm glad you think W1zzard did a "hitpiece" against AMD. Just go ahead and ignore the very positive reviews of Ryzens and their latest GPU's. It also means you are completely ignorant of his early days, which were very much ATI related. Do I need to tell you what ATI was? What he did do was use his very good technical knowledge and investigate, then write a clear, level-headed post which would hopefully help one or two people.

I can tell you from experience helping people, regular people don't know squat and do this kind of thing all the time, and don't know how to fix it. This post will explain it and tell them what to do, since it will now like be a search engine result.
 
Quite a leap you took there, from GPUs to 737 Max. Also are you saying that, Nvidia writes infallible code?
Alot programming gurus in this comment section, maybe you should apply for a job at AMD. Explain to them, how you're going to save them from themselves.

Yeah I should offer AMD a piece of advice: "stop asking your customers to beta test your drivers and hire real beta testers" :roll: .

Well I had some small bugs with Nvidia driver too but they only last for a very short time, like a week or two before a hotfix come out, didn't have to send email to Nvidia or anything.
 
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.
Basically this.

Breaking news: Software installed on computer, does stuff on computer, news at 8.
 
I have Radeon GPU and it still puts one thread at 100% usage. Check following image. i.imgur.com/XEbMEW2.png

You can clearly see I can use Radeon settings just fine and it even picks up GPU but it still takes one thread for itself. I just DDU'ed system again and it didn't change anything. I have to kill Radeon Settings process every time I use it.

Might as well downgrade to like 19.something version, at least it was nice and stable and not bloated.

Doesn't occur here, you might try reinstalling as you suggested.

I'm glad you think W1zzard did a "hitpiece" against AMD. Just go ahead and ignore the very positive reviews of Ryzens and their latest GPU's. It also means you are completely ignorant of his early days, which were very much ATI related. Do I need to tell you what ATI was? What he did do was use his very good technical knowledge and investigate, then write a clear, level-headed post which would hopefully help one or two people.

I can tell you from experience helping people, regular people don't know squat and do this kind of thing all the time, and don't know how to fix it. This post will explain it and tell them what to do, since it will now like be a search engine result.

I've been buying products since the very first Radeon 32SDR became available, so no, you don't have to do the whole condescending attitude and assume. People can make mistakes, they're allowed. Publishing this ridiculous farce was a mistake, though, and admitting mistakes is the first step on the road to admitting problems that may exist.
 
Just confirmed i have this bug on my server - i did a GPU swap from an RX 570 to a GT 610 to save on idle wattage, and it's been sitting at 6.7% CPU usage for almost 10 days now....

p1kalmig2k.jpg

zp5tm1qbi6.jpg


oops.


edit: i tried clicking the tray icon only for it to vanish and stop wasting CPU power, somethings definitely weird on this one.
 
Just confirmed i have this bug on my server - i did a GPU swap from an RX 570 to a GT 610 to save on idle wattage, and it's been sitting at 6.7% CPU usage for almost 10 days now....

p1kalmig2k.jpg

zp5tm1qbi6.jpg


oops.


edit: i tried clicking the tray icon only for it to vanish and stop wasting CPU power, somethings definitely weird on this one.

Hey, it could be using your CPU for mining purposes for all you know :D
 
Quite a leap you took there, from GPUs to 737 Max. Also are you saying that, Nvidia writes infallible code?

Alot programming gurus in this comment section, maybe you should apply for a job at AMD. Explain to them, how you're going to save them from themselves.
cut the I am not a expert so you can't be one either bullshit please if you don't understand the gravity of why this is bad and your only focus is on MaH UnDerDoG please just show your self out

This is not going to have a job tomarrow bad if they find who ever signed off on this (assuming anybody at AMD cares about code quality which we know they don't ) =\

nobody mentioned Nvidia you did so you can stop with the bias crap

if I was AMD I would hire a reputable code auditing service and have them check there entire code for errors like this odds are there is more
 
Just confirmed i have this bug on my server - i did a GPU swap from an RX 570 to a GT 610 to save on idle wattage, and it's been sitting at 6.7% CPU usage for almost 10 days now....
That's exactly why I made this post. So people are like "oh wait, could this affect me?" and spend 30 seconds looking at Task Manager. Guess those idle power savings from GT610 were used up by the CPU ;)
 
so the take away from this are;

1. coders are lazy and,
2. remove software for hardware no longer in the system.

in other news, the sky is blue, grass is green and rain is wet :lol:

before the flames start, i think amd not doing their job is just as bad as leaving software on your system for hardware you removed. both to blame like.
 
AMD bloatware installed with the drivers is very buggy and annoying.

Yesterday I put all OC settings directly in to the bios of my card so don't need use it anymore. Tried using afterburner but it was messing stock bios fan profile up.

Bit extreme maybe but feel much better just using the driver.
 
As a "hobby programmer"(*), i've made similar coding mistakes regarding timeouts with unplugged hardware that i made. I think this article was very informative and as i see it, unbiased.

But things escalate quickly.

(*) I started with C64 basic and asm. Then moved on to PCs and Pascal. After that Delphi and AVR asm. It was very hard to learn Windows programming and while i loved coding, every now and then i needed something new that i had to learn. And part of me hated that. Haven't coded a line like in 8 or 10 years, and now, if i want to start again, i must learn a new language, like C...
 
What am I missing here? @Wizzard you forgot to remove the driver and the software before pulling the gfx card or the coding in the associated driver application is crap. YOU as the user are always supposed to uninstall driver...!!! This WHOLE article could have been condensed down a single line -

"When removing a gfx card remember to always uninstall the driver & associated application, if that doesn't work, use DDU. "
 
Are people not getting that this is just reporting a bug?


Like.... it's a PSA not a call to arms.
 
There is literal evidence of shitty coding practices in the OP of this article. It's not FUD at this point, it's a question of how deep the rabbit hole goes.
You SHOULD be asking yourself how much "fine wine" could be gained by fixing all the sure-to-be-found similar crap in the driver. It could be extraordinary.
Like I argued in #40, the problem Wizz found here is just a symptom of something bigger, the tip of the ice berg if you will. In terms of debugging, we are actually "lucky" when bugs cause consistent stalls or crashes, those are easy to attach a debugger and find, and should be found by AMD if they did proper testing. Most synchronization issues are often much harder to reproduce consistently, and often disappear when you attach a debugger.

I disagree about AMD just fixing similar crap and getting extraordinary results. Don't get me wrong, every bug should be fixed, but the inconsistent reliability issues I've seen over many years with AMD drivers tells me there is probably some larger "design flaw". If this was easily fixable, AMD would have fixed it a long time ago.

Me too. My experience (and attempt to help others) with the 5700 XT is well documented here on the forums. In particular, DX11 cpu overhead is absurd.
Perhaps the overhead is "absurd" if you make an isolated test case, but it's not absurd in practice.
Nevertheless, AMD could easily do what Nvidia did, by bringing most of the driver side improvements of DirectX 12 to 11, but that would ruin the image of AMD being better at DirectX 12 though.

With all due respect, no commercial programmer should make a mistake like this ever. It's... I guess you just have to be a programmer to understand. It's like trying to hard boil an egg without water. It shows you have no business in the kitchen.
Really?
Have you worked at code bases of 100.000s or millions of lines of code, possibly with an awful complex structure?
Keep in mind that we are talking about a minor "glitch" here, which could be either a careless mistake or even the result of a bad merge. All programmers do small mistakes, and I'll be the first one to admit doing some embarrassing ones, but what really shows programming skills (or lack thereof) is how problems are solved, not a tiny mistake. And I mean no disrespect here, but having such attitudes as an engineer is not healthy.

One of the bigger problems I've had in development teams over the years is that lesser coders don't dare to challenge my work, even when I've strongly encouraged them to try to break it. So getting good QA can sometimes be challenging.

Evidence of a mistake, yes. However, the problem that exists strikes me as one that is fairly complicated and not something that could have been anticipated as a potential issue. This was an honest mistake much like the ones Intel, NVidia, Apple, Google, Microsoft, Adobe, etc, etc have made. Computer code is extremely complicated. People really need to stop making mountains out of mole-hills.
Mostly true, yes.
But regarding anticipating issues; all such software projects should have routines designed to validate that a release is working reasonably well. While I don't expect anyone to never make a bug, it is astonishing that they didn't test if the driver behaved erratically in a system with a different GPU present, this should certainly be in their test suite.
Edit: Let me take another example; some years ago AMD managed to ship two drivers in a row, both failing to compile most GLSL shaders, even basic ones. I still don't understand how it's "possible" to ship a driver without validating basic stuff like this.

What am I missing here? @Wizzard you forgot to remove the driver and the software before pulling the gfx card or the coding in the associated driver application is crap. YOU as the user are always supposed to uninstall driver...!!! This WHOLE article could have been condensed down a single line -

"When removing a gfx card remember to always uninstall the driver & associated application, if that doesn't work, use DDU. "
This nonsense has been debunked several times, there are many reasons to have different GPUs present, such as;
APU + GPU
Developers or other engineers having multiple GPUs for various compute and simulations

Even APIs like DirectX 12 and Vulkan is designed to work with multiple GPUs from different makes. There is simply no excuse when a driver suite don't handle this.
 
Last edited:
  • there are many reasons to have different GPUs present, such as - APU + GPU. Developers or other engineers having multiple GPUs for various compute and simulations
  • There is simply no excuse when a driver suite don't handle this.
  • Correct and I have done this myself on a few occasions.
  • There is never an excuse for poorly behaving software, but leaving the driver & associated application installed after the relevent GPU is no longer present is just asking for trouble.
 
Back
Top