Some background - I've been using this machine for years as a fun, cheap, low-power rig to participate in distributed computing programs. It's been upgraded to 8GB of DDR4, which is shared between the CPU and GPU. I've successfully run Folding@Home on its R5 GPU, although it's too slow to turn in modern WUs on time. Folding doesn't cause the core clocks to their maximums, but GPU-Z shows 99% utilization when Folding.

In order to put the GPU to use where it can turn in work on time, I started running GPU units on this machine for Asteroids@Home.

However, I keep getting the "AMD has detected that a driver timeout has occurred on your system" error.

The moment this happens, GPU-Z reflects that Asteroids@Home is no longer being worked on by the GPU, although BOINC doesn't reflect any issue and seems to think the work unit is still being processed. Hitting "Suspend" then "Resume" gets it running again, at least for a few minutes. This driver timeout tends to happen when the GPU work units are at either 0.010% or 0.030%. No GPU WU gets beyond that point. Could this be some kind of checkpointing issue? Is some kind of buffer filling up with work and unable to write progress to disk after a certain amount of work?

You can find many forum posts across the web of the same error message. Mostly people experience this while gaming. Some have found that decreasing their GPU's overclock, using an older driver, or installing the AMD GPU driver but not the Adrenalin software suite, can solve the issue for the, but these don't work for everyone. I've tried all of these, and this GPU isn't overclocked in the first place. Nor is it overheating; it only hits 40°C under load.

I'm posting to see whether anyone here has experienced this error while running Asteroids@Home on an AMD GPU. I know this GPU is weak, and older, but running these projects is fun and, oddly enough, troubleshooting is fun too.

I welcome any thoughts and ideas!

hi, the GPU is extremely slow. Old architecture, 3 cores, and shared memory. The problem is that it triggers Windows protection against GPU freezes.

You can probably fix it by increasing the timeout
https://manual.notch.one/0.9.23/en/docs/faq/extending-gpu-timeout-detection/

but I would rather recommend not to use the GPU at all. Even the Bulldozer cores are more efficient, and utilizing the iGPU will just slow it down.

Thanks for that info, ahorek. I haven't seen that solution posted to address driver timeouts in all the threads I've come across, so I'm looking forward to trying this out.

Yup, it is quite slow - purely a for-fun project for me. How is this old hardware fun? I'll type it out, just because I love talking about this stuff. If you feel like humoring me, read on, otherwise skip to the last paragraph of this post.

Stoney Ridge (2016) is the mobile version of Bristol Ridge, which itself is the final, most developed iteration of the original Bulldozer platform (2011). It's... not fast, and that's fine with me. I just want to play around without running up the electric bill, and still turn in WUs on time. I got this machine 3 years ago on shopgoodwill.com because it was the perfect storm of fanless + low power usage, sufficient (kinda) modernity to run a few fun background processing tasks, including what's technically a GCN GPU, albeit a hilarious one. I love tinkering with old hardware that's on the edge of relevance. It runs a Bitcoin Core x64 node, takes turns on various BOINC projects, used to Fold (too slow on GPU at this point), and it serves as an always-on basic NAS using a USB HDD. I also VNC in regularly to collect E-Tree points in Edge, since I can't do that at work due to IT policy. None of my other, much more powerful, machines run constantly. This is a $30 project PC that's given me countless hours of tinkering. I upgraded the cooling and RAM (which increased available VRAM), updated to Win11, made all kinds of OS tweaks, did some Afterburner experiments, etc. I want this A9-9420e to be the one that's accomplished the most out of all of its ilk on the planet. It's a fun project that costs me almost nothing to run.

The Asteroids plan is to stop the machine's other tasks and run only GPU WUs for a bit. See what CPU usage is like. If I can get GPU WUs running, If GPU WUs are less productive than CPU WUs, or if they require so much CPU support that it doesn't make sense to also run CPU WUs using the remaining % of available CPU time less GPU WU support, I'll proceed accordingly. Seeing how much I can get out of this little fanless thing - this is where the fun is for me! I'd like these GCN cores to be doing something, though, so I hope the math ends up making sense, that this APU can do more by running CPU + GPU WUs than on CPU alone. That's why I went with an APU-based PC.

This may not sound like fun to a lot of people, but I love it, and clearly love talking about it! Either way my friend, I appreciate the advice on dealing with the driver timeout. I will try this and update with results.

Update. I created the TdrDelay registry key as a DWORD (32-bit value) in:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers

and set it Decimal (rather than Hexadecimal) with a value of 60, which the unlisted unit being seconds.

After rebooting, with no Windows Updates being installed, the key was gone. I added it again, rebooted, and it remained. Clicking into the key, its default way of displaying itself is as Hexadecimal, which is fine. Clicking it over to Decimal shows that the value will still be 60, or whatever you set it as. Doesn't matter whether it wants to think of itself as a Hex instead.

This resolved the GPU driver timeout issue. GPU WUs are now running on the A9-9420e's R5 APU, anemic as it is. I haven't tested other values for this key and AFAIK don't have a reason to do so. If I get bored and try that, and find that lowering the value affects performance in some way, I'll add a comment to this thread about it. If not, I won't.

Thanks to ahorek's team for the suggestion with this!

Pushing the GPU beyond its limits may lead to GUI unresponsiveness, and a malfunctioning application could cause the system to freeze, and a hard reset will be the only option to recover it. Windows protection monitors your GPU and resets the driver if such issues occur, but resetting the GPU will cause the task to fail.
With very slow GPUs, you're more likely to encounter timeout crashes since the default timeout value is the same across all GPUs, regardless of their performance.

Ideally, the application should assess your GPU's capabilities and process smaller data chunks. This would improve GUI responsiveness and prevent timeouts, although it will also slow down the application. Each GPU model is unique, making it challenging to find the right balance that consistently works across all systems, and splitting work into smaller pieces isn't always as simple as it sounds.

Given that your GPU technically has the capability to run those tasks, it still processes them slower than most 20-year-old CPUs. If you're still set on using it on Windows, despite the insane inefficiency, increasing the timeout could be a reasonable workaround.