Why is DiabloMiner using so much CPU now?

Question

DiabloMiner uses about one 50% of CPU on my system (distributed among 2 cores). I could have sworn that it used almost no CPU (1-2% max) in older versions, but I'm not really sure if I should report this as a bug or not. So, is it normal, or am I correct in remembering that GPU miner should not use more than 1-2% of CPU while mining?

Link: Possibly related question.

Answer 1

I'm surprised you just didn't ask me directly.

It sounds a lot like you're suffering from one of two CPU use bugs in the driver. Catalyst 11.7 through 11.11 (using any SDK) use 100% CPU time on one or more cores because of a faulty sleep, and SDK 2.2 and 2.3 (using any Catalyst) also have the same exact issue.

However, Windows has a third variation of the bug, if you set -f too low (ie, kernel work size or kernel execution time exceeds a predefined amount), it can also trigger Windows into stating the CPU is being used 100%, however this does not seem to be a driver bug and is a bug in Windows itself.

Edit: My answer was strictly for AMD hardware. If you're on Nvidia, Nvidia is aware of the bug (it happens on any OpenCL app), but they have not yet fixed it.

Answer 2

It almost certainly is related to the question you linked and it almost certainly has the same answer I'm sad to say. There is a lot of this going around and no one is really certain what exactly is causing it.

There have been reports that ATI's 11-7_vista64_win7_64_dd_ccc_ocl drivers often bring the problem about, and reverting back to an 11-6 version seems to fix it. Not sure if it will work for you or if it even applies to your situation but it's worth a shot.

Answer 3

One of your CPUs is spin-waiting for the GPU to finish work units. Generally, GPU drivers have two options to wait for the hardware: either suspend the process until an interrupt is generated, or poll the GPU whether it is finished in a tight loop. It seems your driver is using the second approach and thus takes 100% CPU of one core.

The advantage of polling is that there is less latency than with interrupts, for example when doing real-time work on the GPU; but in case of a background process like mining which hardly requires CPU intervention, sleeping would be a better option.

It might be that ATI changed this in recent drivers. In CUDA this is an option when creating the compute context (SCHED_AUTO/SCHED_SPIN/SCHED_YIELD) to choose the waiting method, but alas, I know of no such option for OpenCL.