<p>I think the most efficient way might be either</p>

<pre><code>return float(shadowValue &gt; shadowTexZ);
</code></pre>

<p>or</p>

<pre><code>return step(shadowTexZ, shadowValue);
</code></pre>

CC BY-SA 3.0
2016-09-25T11:40:28.387Z
Could you share you reasons for settling on these approaches? The logic behind it or profiling evidence perhaps?
trichoplax is on Codidact now
CC BY-SA 3.0
2016-09-25T14:30:10.763Z
The first one to me seems like the most straightforward approach to obtain the desired result and the second one is something the GPU potentially might be better suited for than comparisons and type casting. Maybe I'm completely wrong, but it's worth a try at least.
Detheroc
CC BY-SA 3.0
2016-09-25T18:55:57.403Z
These seem like points worth expanding your answer with.
trichoplax is on Codidact now
CC BY-SA 3.0
2016-09-24T19:55:23.803Z
2016-09-24T19:55:23.803Z
Detheroc
<p>Working on optimizing a fragment shader which is slowing down my OpenGL ES 2.0 shader based game. This is used with a shadow buffer to determine if the fragment/pixel is inside a shadow volume.</p>

<p>The problem/slowdown is the fact I need a branch if or function to determine a 1.0 (no shadow) or 0.0 (shadowed) based on comparison of the frag's shadow Z and shadow buffer Z.</p>

<pre><code>    // SLOWEST
    if ( shadowValue &gt; shadowTexZ ) return 1.0; else return 0.0;

    // ALSO SLOW
    return clamp( 1.0 + (shadowValue - shadowTexZ) * 1000.0, 0.0, 1.0 );

    // SLIGHT LESS SLOW
    return max(sign(shadowValue - shadowTexZ), 0.0);

    // ALSO SLOW
    return sign( shadowValue - shadowTexZ ) * 0.5 + 0.5;
</code></pre>

<p>If I disable the shadow test all together, GPU time in Xcode is 12ms and solid 60fps.  With the test on it jumps to 26ms and drops the framerate unacceptably to 40fps.</p>

<p>Thanks!</p>

CC BY-SA 3.0
2016-09-23T23:22:27.310Z
I wonder if it's the texture read(s?) that are slow.  If you don't use the value that results from the texture read, it probably isn't even doing the texture read.  You could try doing dummer math with those values to see if it's still slow.  like maybe return shadowValue + shadowTexZ;
Alan Wolfe
CC BY-SA 3.0
2016-09-24T04:42:17.613Z
I also think the compiler may be optimizing out some parts of your code if you comment this line. Please check the lower level generated code to be sure. Moreover, you should check the step function documentation for optimizing out this particular branch.
vgs
<opengl><shader><optimisation><fragment-shader><opengl-es>
OpenGL ES Frag Shader - Branching
Blaine Hodge
# OpenGL ES Frag Shader - Branching

(Asked by: username_0 on 2016-09-23)

Working on optimizing a fragment shader which is slowing down my OpenGL ES 2.0 shader based game. This is used with a shadow buffer to determine if the fragment/pixel is inside a shadow volume.

The problem/slowdown is the fact I need a branch if or function to determine a 1.0 (no shadow) or 0.0 (shadowed) based on comparison of the frag's shadow Z and shadow buffer Z.

```
    // SLOWEST
    if ( shadowValue > shadowTexZ ) return 1.0; else return 0.0;

    // ALSO SLOW
    return clamp( 1.0 + (shadowValue - shadowTexZ) * 1000.0, 0.0, 1.0 );

    // SLIGHT LESS SLOW
    return max(sign(shadowValue - shadowTexZ), 0.0);

    // ALSO SLOW
    return sign( shadowValue - shadowTexZ ) * 0.5 + 0.5;

```

If I disable the shadow test all together, GPU time in Xcode is 12ms and solid 60fps. With the test on it jumps to 26ms and drops the framerate unacceptably to 40fps.

Thanks!

**Tags:** opengl, shader, optimisation, fragment-shader, opengl-es

> **Comments:**
> **username_1**: I wonder if it's the texture read(s?) that are slow.  If you don't use the value that results from the texture read, it probably isn't even doing the texture read.  You could try doing dummer math with those values to see if it's still slow.  like maybe return shadowValue + shadowTexZ;  
> **username_2**: I also think the compiler may be optimizing out some parts of your code if you comment this line. Please check the lower level generated code to be sure. Moreover, you should check the step function documentation for optimizing out this particular branch.  

---

## 1 answers

### Answer by username_3 on 2016-09-24. Score: 3 | Accepted answer

I think the most efficient way might be either

```
return float(shadowValue > shadowTexZ);

```

or

```
return step(shadowTexZ, shadowValue);

```

> **Comments:**
> **username_4**: Could you share you reasons for settling on these approaches? The logic behind it or profiling evidence perhaps?  
> **username_3**: The first one to me seems like the most straightforward approach to obtain the desired result and the second one is something the GPU potentially might be better suited for than comparisons and type casting. Maybe I'm completely wrong, but it's worth a try at least.  
> **username_4**: These seem like points worth expanding your answer with.  

---

