<p>In your specific example, where there are no race conditions, as long as the workgroup size is a multiple of what the architecture requires (wavefront/warp) there would be no difference as the GPU/driver will schedule as it see's fit and in all likelyhood, the GPU would be fully saturated in both cases.</p>
<p>However, if a specific shaders computation is quite heavy (each shader doing a lot), or they are unbalanced wrt to workload (one invocation in a group takes a lot longer than the rest of the group/other groups, 'delaying' the completion of that group), this may trigger a TDR (Timeout, Delay and Recovery) when invoking a lot of workgroups in a single dispatch.</p>
<p>In these scenarios it is better to lighten the work each shader does (split algorithm into more digestable stages so that the workload is more balanced across the workgroup, and ideally across all workgroups) and/or dispatch batches, flushing/finishing inbetween batches so to keep the OS happy. Balancing the workgroup count vs number of dispatches can be quite difficult when targeting a wide gamut of hardware to achieve optimal performance and may require a 'calibration'/dry-run at runtime to deduce a safe batch size/workgroup count.</p>

CC BY-SA 4.0
2023-04-29T00:03:13.797Z
2023-04-29T07:03:24.417Z
2023-04-29T07:03:24.417Z
lfgtm
<p>I know, that when using compute shader, the invocations should to be grouped with respect to a multiple of the hardware minimum workgroup size (Nvidia 32, AMD 64). Otherwise cores are blocked. In case of no communication between invocations is required, does it makes sense to use a bigger workgroup size than the minimum workgroup size of 32 or 64?</p>
<p>So let's say we have 320 particles which need to be calculated. No collision detection, no communication between them... and we are working on a Nvidia machine. Is there a performance boost to create one workgroup with 320 invocations instead of using 10 times one workgroup with 32 invocations?</p>
<p>Or to put it another way, does the size of the workgroup make a difference, aside from the ability to use shared memory?</p>
<p>Are there benefits to use smaller workgroup sizes?</p>

CC BY-SA 4.0
2023-04-28T22:09:07.007Z
*Or to put it another way, does the size of the workgroup make a difference, aside from the ability to use shared memory?* It does. GPU's schedule compute units in minimum work group sized chunks. So if a group of 8 is sent out, 32 units(on Nvidia) are going to be tied up while all 8 finish. Nothing can be scheduled in those idle units while the others are working.
pmw1234
CC BY-SA 4.0
2023-04-29T10:34:57.810Z
@pmw1234 I know... Like I said: grouped with respect to a multiple of the hardware minimum workgroup size (Nvidia 32, AMD 64). Otherwise cores are blocked...
Thomas
<compute-shader>
Workgroup size performance change?
Thomas
# Workgroup size performance change?

(Asked by: username_0 on 2023-04-28)

I know, that when using compute shader, the invocations should to be grouped with respect to a multiple of the hardware minimum workgroup size (Nvidia 32, AMD 64). Otherwise cores are blocked. In case of no communication between invocations is required, does it makes sense to use a bigger workgroup size than the minimum workgroup size of 32 or 64?

So let's say we have 320 particles which need to be calculated. No collision detection, no communication between them... and we are working on a Nvidia machine. Is there a performance boost to create one workgroup with 320 invocations instead of using 10 times one workgroup with 32 invocations?

Or to put it another way, does the size of the workgroup make a difference, aside from the ability to use shared memory?

Are there benefits to use smaller workgroup sizes?

**Tags:** compute-shader

> **Comments:**
> **username_1**: *Or to put it another way, does the size of the workgroup make a difference, aside from the ability to use shared memory?* It does. GPU's schedule compute units in minimum work group sized chunks. So if a group of 8 is sent out, 32 units(on Nvidia) are going to be tied up while all 8 finish. Nothing can be scheduled in those idle units while the others are working.  
> **username_0**: @username_1 I know... Like I said: grouped with respect to a multiple of the hardware minimum workgroup size (Nvidia 32, AMD 64). Otherwise cores are blocked...  

---

## 1 answers

### Answer by username_2 on 2023-04-29. Score: 1 | Accepted answer

In your specific example, where there are no race conditions, as long as the workgroup size is a multiple of what the architecture requires (wavefront/warp) there would be no difference as the GPU/driver will schedule as it see's fit and in all likelyhood, the GPU would be fully saturated in both cases.

However, if a specific shaders computation is quite heavy (each shader doing a lot), or they are unbalanced wrt to workload (one invocation in a group takes a lot longer than the rest of the group/other groups, 'delaying' the completion of that group), this may trigger a TDR (Timeout, Delay and Recovery) when invoking a lot of workgroups in a single dispatch.

In these scenarios it is better to lighten the work each shader does (split algorithm into more digestable stages so that the workload is more balanced across the workgroup, and ideally across all workgroups) and/or dispatch batches, flushing/finishing inbetween batches so to keep the OS happy. Balancing the workgroup count vs number of dispatches can be quite difficult when targeting a wide gamut of hardware to achieve optimal performance and may require a 'calibration'/dry-run at runtime to deduce a safe batch size/workgroup count.


---

