<p>A compute shader defines the number of threads it requires to be executed.<br>
This number can be called "local size" or "threadgroup size" according to the API, and be factored into 3 separate dimensions X * Y * Z.
If an algorithm only requires at minimum a small number of threads to be executed, is it more performant to define this number as the local size, and let the GPU handle the parallelization of its execution over a large data-set?<br>
Or is there any benefit in using a bigger local size?</p>

CC BY-SA 4.0
2018-07-12T06:32:48.323Z
That would depend on the hardware that'll be running the threads, and how exactly your algorithm is implemented (its hardware usage). If you experiment with the different thread numbers and run your hardware vendor's performance profiler tools, you can get an idea of how the thread groups are utilizing your hardware in general. To my (little) experience, there's no general solution to this and it always depends on the hardware and the shader code specifics.
Varaquilex
CC BY-SA 4.0
2018-07-12T07:08:55.367Z
Thank you. I recently heard that it was recommended to use a multiple of the GPU's "Thread Warp"/"Wavefront" size, but that this should not prevent from doing tests with the specific shader and HW
wip
CC BY-SA 4.0
2018-07-12T07:51:04.527Z
Exactly. At the end of the day, the code will run on the hardware and the hardware will determine the performance. Understanding the resource usage of a shader program through the right tools and figuring out how the algorithm scales over different architectures / configurations through little experimentation is the way to go in my humble opinion. It would be interesting to hear from the more seasoned programmers though.
Varaquilex
<performance><compute-shader>
Is a smaller local-size/threadgroup-size better for compute shader performance?
wip
# Is a smaller local-size/threadgroup-size better for compute shader performance?

(Asked by: username_0 on 2018-07-09)

A compute shader defines the number of threads it requires to be executed.  
This number can be called "local size" or "threadgroup size" according to the API, and be factored into 3 separate dimensions X \* Y \* Z.
If an algorithm only requires at minimum a small number of threads to be executed, is it more performant to define this number as the local size, and let the GPU handle the parallelization of its execution over a large data-set?  
Or is there any benefit in using a bigger local size?

**Tags:** performance, compute-shader

> **Comments:**
> **username_1**: That would depend on the hardware that'll be running the threads, and how exactly your algorithm is implemented (its hardware usage). If you experiment with the different thread numbers and run your hardware vendor's performance profiler tools, you can get an idea of how the thread groups are utilizing your hardware in general. To my (little) experience, there's no general solution to this and it always depends on the hardware and the shader code specifics.  
> **username_0**: Thank you. I recently heard that it was recommended to use a multiple of the GPU's "Thread Warp"/"Wavefront" size, but that this should not prevent from doing tests with the specific shader and HW  
> **username_1**: Exactly. At the end of the day, the code will run on the hardware and the hardware will determine the performance. Understanding the resource usage of a shader program through the right tools and figuring out how the algorithm scales over different architectures / configurations through little experimentation is the way to go in my humble opinion. It would be interesting to hear from the more seasoned programmers though.  

---

## 0 answers

