<p>Not all threads will execute in lockstep but they are split into groups whose threads are locked to each other.</p>

<p>This means that if only 1 thread out of all threads enters a branch then only 1 group will need to enter that branch while all the others will skip it.</p>

<p>In that group that has to execute both branches it will actually execute both branches but threads will throw away the result of the branch that it didn't need to go into.</p>

<p>For more information <a href="https://computergraphics.stackexchange.com/q/280/137">see this question</a>.</p>

CC BY-SA 3.0
2016-05-26T12:13:00.820Z
@nikitablack depends on the hardware and is kinda impossible to extract naively from any marketing information.
ratchet freak
CC BY-SA 3.0
2016-05-26T12:16:15.593Z
And also a question. Lets's say one thread in a group reads from some buffer in a branch based on that thread's id. Lets's say the buffer size is 1, so only the first thread can read, all other threads will cause out of bounds read. Is it safe? And one more thing - the read from the system memory is very slow, but all threads will read from it, even if they don't need, right?
nikitablack
CC BY-SA 3.0
2016-05-26T13:12:26.167Z
@nikitablack that's going to depend on a few things; 1) if the driver is smart enough to forward the constant in the test into the then clause, 2) if the hardware can do a "masked read", 3) what exactly happens on out of bounds reads
ratchet freak
CC BY-SA 3.0
2016-05-26T17:13:09.697Z
@nikitablack The lockstep group size is 32 for NVIDIA and 64 for AMD (they call them "warps" and "wavefronts" respectively). For Intel the size is variable from 8 to 32, determined by the shader compiler. Also, out-of-bounds reads are defined to just return zero in DirectX, and I'm pretty sure it's the same for GL and the other APIs.
Nathan Reed
CC BY-SA 3.0
2016-05-27T07:57:30.677Z
For the reason Nathan just described, you should always make your work group size a multiple of 64 to avoid wasting shader invocations in the last warp / wavefront of each group. If you don't need to use shared variables, exactly 64 is usually a good size.
russ
CC BY-SA 3.0
2016-05-26T12:02:55.647Z
2016-05-26T12:02:55.647Z
2017-04-13T13:00:43.660Z
ratchet freak
<p>I'm working with <code>DirectCompute</code>, but this question can be applied to general gpu programming I suppose.</p>

<p>As far as I know the threads in a group works in a lockstep. It means that every instruction for every thread executes at the same time, right? But what if one thread out of <code>1024</code> entered <code>if/else</code> condition? All other <code>1023</code> will just wait or lockstep condition will be violated?</p>

<compute-shader>
Threads lockstep and conditions in compute shader
nikitablack
# Threads lockstep and conditions in compute shader

(Asked by: username_0 on 2016-05-26)

I'm working with `DirectCompute`, but this question can be applied to general gpu programming I suppose.

As far as I know the threads in a group works in a lockstep. It means that every instruction for every thread executes at the same time, right? But what if one thread out of `1024` entered `if/else` condition? All other `1023` will just wait or lockstep condition will be violated?

**Tags:** compute-shader


---

## 1 answers

### Answer by username_1 on 2016-05-26. Score: 5 | Accepted answer

Not all threads will execute in lockstep but they are split into groups whose threads are locked to each other.

This means that if only 1 thread out of all threads enters a branch then only 1 group will need to enter that branch while all the others will skip it.

In that group that has to execute both branches it will actually execute both branches but threads will throw away the result of the branch that it didn't need to go into.

For more information [see this question](https://computergraphics.stackexchange.com/q/280/137).

> **Comments:**
> **username_1**: @username_0 depends on the hardware and is kinda impossible to extract naively from any marketing information.  
> **username_0**: And also a question. Lets's say one thread in a group reads from some buffer in a branch based on that thread's id. Lets's say the buffer size is 1, so only the first thread can read, all other threads will cause out of bounds read. Is it safe? And one more thing - the read from the system memory is very slow, but all threads will read from it, even if they don't need, right?  
> **username_1**: @username_0 that's going to depend on a few things; 1) if the driver is smart enough to forward the constant in the test into the then clause, 2) if the hardware can do a "masked read", 3) what exactly happens on out of bounds reads  
> **username_2**: @username_0 The lockstep group size is 32 for NVIDIA and 64 for AMD (they call them "warps" and "wavefronts" respectively). For Intel the size is variable from 8 to 32, determined by the shader compiler. Also, out-of-bounds reads are defined to just return zero in DirectX, and I'm pretty sure it's the same for GL and the other APIs.  
> **username_3**: For the reason username_2 just described, you should always make your work group size a multiple of 64 to avoid wasting shader invocations in the last warp / wavefront of each group. If you don't need to use shared variables, exactly 64 is usually a good size.  

---

