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?
$\begingroup$
$\endgroup$
3
-
1$\begingroup$ 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. $\endgroup$– VaraquilexJul 12, 2018 at 6:32
-
$\begingroup$ 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 $\endgroup$– wipJul 12, 2018 at 7:08
-
1$\begingroup$ 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. $\endgroup$– VaraquilexJul 12, 2018 at 7:51
Add a comment
|