<p>I'm surprised you just didn't ask me directly.</p>

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

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

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

CC BY-SA 3.0
2012-02-23T10:12:25.110Z
2012-02-23T10:21:20.373Z
2012-02-23T10:21:20.373Z
Diablo-D3
<p>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.</p>

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

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

CC BY-SA 3.0
2011-09-18T12:15:51.060Z
This makes sense. Is is possible to change this setting in either NVIDIA or ATI driver, or is this only the privilege of driver makers?
Domchi
CC BY-SA 3.0
2011-09-01T11:13:54.577Z
2011-09-01T11:13:54.577Z
laanwj
<p>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.</p>

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

CC BY-SA 3.0
2011-09-01T08:47:02.697Z
Curiously, I'm experiencing the same on NVIDIA card (yeah, not seriously into mining), so I guess the problem is in OpenCL instead of in manufacturer's drivers themselves.
Domchi
CC BY-SA 3.0
2011-08-31T21:51:06.337Z
2011-08-31T21:51:06.337Z
David Perry
<p>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?</p>

<p>Link: <a href="https://bitcoin.stackexchange.com/questions/172/why-does-poclbm-acquire-100-cpu">Possibly related question.</a></p>

<diablominer><gpu-mining>
Why is DiabloMiner using so much CPU now?
Domchi
# Why is DiabloMiner using so much CPU now?

(Asked by: username_0 on 2011-08-31)

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.](https://bitcoin.stackexchange.com/questions/172/why-does-poclbm-acquire-100-cpu)

**Tags:** diablominer, gpu-mining


---

## 3 answers

### Answer by username_1 on 2012-02-23. Score: 2 | Accepted answer

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 by username_2 on 2011-09-01. Score: 2

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.

> **Comments:**
> **username_0**: This makes sense. Is is possible to change this setting in either NVIDIA or ATI driver, or is this only the privilege of driver makers?  

---

### Answer by username_3 on 2011-08-31. Score: 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.

> **Comments:**
> **username_0**: Curiously, I'm experiencing the same on NVIDIA card (yeah, not seriously into mining), so I guess the problem is in OpenCL instead of in manufacturer's drivers themselves.  

---

