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

[wolf]

So AMD bad, Intel and nVidia good. This is BS article to make AMD look bad.

I don't even know where to start with this one... but if your accusing @W1zzard of being a 'shill' and having no intention other than dumping on AMD to make them look bad, you don't know his standards very well.

This sort of constructive journalism gets issues fixed.

 

[lexluthermiester]

I don't even know where to start with this one... but if your accusing @W1zzard of being a 'shill' and having no intention other than dumping on AMD to make them look bad, you don't know his standards very well.

This sort of constructive journalism gets issues fixed.

No one can call W1z a shill, he's way too objective. This is a flat-out weird-as-hell glitch/bug discovery. AMD will fix this, but they needed the nitty-gritty break-down like this to know what to look at and what to fix...
@hurakura you need to stop that nonsense, you're embarrassing yourself.

 

[R-T-B]

Looks like Wizzard kicked over a hornets nest before leaving for the weekend.

I think maybe that's why he timed it how he did.

Fanboyism can be a vicious, blinding thing.

I really don't think AMD did this deliberately. It's got to be an unintentional problem...

Oh it's completely unintentional, but that doesn't make it any less stupid.

For a rather extreme analogy, Chernobyl was unintentional. It was also completely brought about by lax practices.

 

[Sybaris_Caesar]

I really don't think AMD did this deliberately. It's got to be an unintentional problem...


No. Just no. No hardware maker has ever had a perfect track record for their drivers and software suites. However, few have ever failed to to provide fixes and updates.

You don't get me. When I see AMD's lacklustre Ray Tracing presentation and support in games I'm not disappointed. If AMD's DLSS counterpart sucks I won't be disappointed. It's AMD after all. AMD never invested in Crossfire so much that SLI is synonymous with multi-GPU, I never cared. It's AMD after all. AMD never had good OpenGL and DirectX 11 drivers but I wasn't disappointed, it's AMD after all. This guy in our forum can't play his games right now. I'm not disappointed cause it's AMD after all. This guy sold his 5600 XT after battling with issues for a year and I'm not disappointed. It's AMD after all. AMD locked 6800 XT to 2.8 Ghz and 6900 XT to 3.0 Ghz when they could literally have overclocking champs. Buildzoid the self-proclaimed AMD fan might be disappointed, der8auer could be disappointed but I'm not.

I just automatically set my expectations and hopes low for any AMD Radeon product.

 

[R-T-B]

I just automatically set my expectations and hopes low for any AMD Radeon product.

And that's not really much wiser than expecting it always to be the best.

I don't expect much of anything. I research and buy. And research like this makes me glad I avoided a potential virtual landmine.

 

[lexluthermiester]

Oh it's completely unintentional, but that doesn't make it any less stupid.

The more I look at the details the more I think it's an honest mistake, not a stupid one. Probably easily corrected with a quick patch.

For a rather extreme analogy, Chernobyl was unintentional. It was also completely brought about by lax practices.

Yup, that's out there...

You don't get me.

No, I got you. I think you're not being very objective and holding a grudge.

 

[R-T-B]

Yup, that's out there...

lol, Didn't say it wasn't, but it's the same degree of facepalm inducing error that you know was followed by others.

The shoe fits on the error foot, if not the severity one.

 

[Sybaris_Caesar]

No, I got you. I think you're not being very objective and holding a grudge.

I'm not claiming to be the bastion of objectivity. But yes I know that everyone fucks up software sometimes. And otoh AMD produces good software sometimes. Anyway I'll end this back-and-forth. It's going nowhere.

 

[W1zzard]

Well he did the mistake on a SSD test system. If hes doing that on a test systems i.e. not cleaning it while switching hardware and drivers. Its not far fetched what else has happened we havent had a PSA for.

Of course I didn't test (benchmark) anything like that, you think I don't know? I tested a new build of GPU-Z using Remote Debugger, on NVIDIA, to check some code changes. Benchmark performance is irrelevant in this case

He run the game's benchmark. Ultra settings in game, stock settings for the card and Ryzen, 50 fps at 1440p. Your testing reported 39.6 fps.

The benchmark is useless, it does not represent actual gaming performance. Play the game, stand in Athens, what's the FPS? Turn around, what's the FPS now?

An application that goes with hardware you've uninstalled wasn't removed, and doesn't know the hardware was removed

Of course it can know that the hardware isn't present anymore. Otherwise we wouldn't be seeing this problem at all. The DVR software does check for AMD hardware and doesn't start, the Settings software does not, and waits forever for the DVR software to start.

multi-GPU bugs are left in GPU-Z

More details please, ideally in the GPU-Z bug report forum.

Be careful when doing performance evaluations because such issues could skew results

They definitely will, which is why I mentioned the 0.5% FPS difference even on a 8c/16t system. I wouldn't be surprised if this affected some less experienced reviewers. As mentioned above I did not benchmark anything on this dual-core machine.

You better explain yourself what you doing with dual core!

See beginning of this post. It's an old system that's useful to have around, and it works surprisingly well for these tasks.

It doesn't care about the why. Its software. You can explain why you tried using an unsupported graphics card all day but it doesnt change anything. AMD might need to patent some sort of mechanism that comes out of the PC and slaps the GPU out of your hand. Until that time comes software can only stop you from installing when you have an incompatible GPU in.

This is not how it works. Windows enumerates all hardware on bootup and does not load drivers for devices that are not present. Go to Device Manager and check "Show Hidden Devices". All these devices are "installed" in your system, and have the driver ready to go.

It's a bug not a conspiracy

I really don't think AMD did this deliberately. It's got to be an unintentional problem...

Of course not, this is just a mistake

I guess next to test is nVidia driver on a system whit Intel CPU and AMD gpu?

That's a great idea. If I find something, do you want me to post an article?

 

[_Flare]

When ReLive was invented it made some problems around 2018 or so.
after quick googling i found this

AMD Relive: Host Application High CPU Usage

Having an issue with high cpu usage on driver 18.4.1. Task manager shows 30% cpu usage. Now the problem persists with previous relive drivers, 18.3.1, 18.2.1. The only solution is to end task or rename dvrcmd.exe so it wont execute. HWInfo64 doesn't install since this issue came up. Gigabyte...

community.amd.com

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.

 

[kruk]

@W1zzard: I somehow can't reply or quote directly, so I'm just pasting it:

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.

Yes, the segment should definitely stop after reaching a threshold, but what if this check was always performed elsewhere and was removed at some point? Then the programmer that wrote this section didn't do anything wrong. In large codebases with big teams, this can happen. It could be a simple communication error ... Since QA probably doesn't test this on computers without Radeon GPUs, it's easy to see why it went undetected.

I hope you reported the bug ...

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.

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 ...

 

[Frick]

This article is such crap. Usually I like reading techpowerup, but a professional video card reviewer who doesn't do a DDU when switching GPUs??? Then saying there is a definite performance drop, 150 vs 151, a whole .5%. That sounds within margin of error. To top it off, there's no test to see if this is true going from Nvidia to AMD.

Then there are people on here who seem to believe that there's no need to uninstall drivers for major hardware changes. I'm sorry, but a GPU is a major hardware change. Do you guys also not cleanup your systems when you change from CPU vendors or change chipsets?

I've swapped systems entirely without reinstalling Windows (10), sometimes it has worked fine, sometimes less fine. I long for the day I never have to reinstall Windows again, but stuff like this highlights that we're not there yet and may never be.

 

[W1zzard]

That is fine in theory, but what if debounced listener has problems catching the signals?

Not 100% sure what you are asking, but the OS makes certain guarantees about Events, they are unique and thread-safe

 

[TheGoddessInari]

More details please, ideally in the GPU-Z bug report forum.

You commented on the bug several times, and said GPU reporting 0/0mhz values on Vega cards in multi-GPU configs wasn't an issue with your software (and only your software specifically, everything else has no issues), while leaving it unfixed forever.

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?

 

[laszlo]

even an inexperienced user won't install amd drivers for nv card ...only if he really don't know the difference

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

 

[john_]

The benchmark is useless, it does not represent actual gaming performance. Play the game, stand in Athens, what's the FPS? Turn around, what's the FPS now?

When comparing GPUs the whole story is to compare them under the same conditions and with the same parameters. You said that

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

When you point at those difficulties in getting accurate readings, I believe you have to use the benchmark. Even if you don't like it. Because you want to compare video cards, or cpus under the absolute same conditions. You do extra performance tests when you are reviewing the game to see how specific hardware, does in all those different situations and how the game's graphic engine performs in different areas of the game. In a city with multiple NPCs visible, in the woods with plenty of vegetation, in an open field with just that dynamic weather. Running the game under a specific scenario, for example in a city, could be making it more CPU bound giving an extra advantage in high IPC CPUs, in the woods maybe it needs higher memory bandwidth from the graphics card favoring those cards and in an open field maybe it can hide in a small degree the differences in performance between different hardware because the scene is less demanding from both CPU and GPU.

 

[0x4452]

this issue may affect mostly the reviewers if they just swap the cards in the test system

I think that's a very good point. If a reviewer just swaps GPUs without uninstalling drivers, the NVIDIA card will be disadvantaged because the AMD driver will hose up a CPU core.

 

[TheGoddessInari]

I think that's a very good point. If a reviewer just swaps GPUs without uninstalling drivers, the NVIDIA card will be disadvantaged because the AMD driver will hose up a CPU core.

If a reviewer does this, they're literally not doing their job, and would get fired.

 

[turbogear]

I always use DDU (Display Driver Uninstaller) before I change my GPU especially when switching from AMD to NVIDIA or vise versa.

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.

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.
In any case I did not wanted to take the risk of having unexplained problems.

 

[efikkan]

So AMD bad, Intel and nVidia good. This is BS article to make AMD look bad. Why do you have drivers installed for a hardware not in the PC? I guess next to test is nVidia driver on a system whit Intel CPU and AMD gpu?

So should we avoid showcasing bugs for AMD then, just in case you fanboys can't handle it?

This article is such crap. Usually I like reading techpowerup, but a professional video card reviewer who doesn't do a DDU when switching GPUs???

He provided a disassembly of a bug, then provided a translation to C for clarity along with an explanation.
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.

Then there are people on here who seem to believe that there's no need to uninstall drivers for major hardware changes. I'm sorry, but a GPU is a major hardware change. Do you guys also not cleanup your systems when you change from CPU vendors or change chipsets?

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?

I really don't think AMD did this deliberately. It's got to be an unintentional problem...

In 99.999% of cases such bugs are accidents, negligence, incompetence, etc.
I seriously hope no one in here thinks such bugs are intentional.

when changing gpu and manufacturer the old driver usually is uninstalled but it may happen to remain...

What?
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.

 

[laszlo]

What?
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.

you have on your pc 2 dedicated gpu's one amd and one nv?

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...

 

[DeathtoGnomes]

I gave up trying to read everything, so Ill just say this... Thanks @W1zzard for doing this.

 

[Mussels]

You don't get me. When I see AMD's lacklustre Ray Tracing presentation and support in games I'm not disappointed. If AMD's DLSS counterpart sucks I won't be disappointed. It's AMD after all. AMD never invested in Crossfire so much that SLI is synonymous with multi-GPU, I never cared. It's AMD after all. AMD never had good OpenGL and DirectX 11 drivers but I wasn't disappointed, it's AMD after all. This guy in our forum can't play his games right now. I'm not disappointed cause it's AMD after all. This guy sold his 5600 XT after battling with issues for a year and I'm not disappointed. It's AMD after all. AMD locked 6800 XT to 2.8 Ghz and 6900 XT to 3.0 Ghz when they could literally have overclocking champs. Buildzoid the self-proclaimed AMD fan might be disappointed, der8auer could be disappointed but I'm not.

I just automatically set my expectations and hopes low for any AMD Radeon product.

You think gaming on 8GB of ram is AMD's fault?

Perhaps you're biased and reaching for examples...

you have on your pc 2 dedicated gpu's one amd and one nv?

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...

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

 

[Flaky]

This sort of constructive journalism gets issues fixed.

This!

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.

when changing gpu and manufacturer the old driver usually is uninstalled but it may happen to remain...

"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.

 

[laszlo]

You think gaming on 8GB of ram is AMD's fault?

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

onboard graphic don't count in this case as hardware wise is always present so driver or not it can't create any issues

This!

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'm aware it won't uninstall by itself but user can do it and when changing manufacturer is common sens no?