<p>There is a difference between being able to determine value at compilation time and at runtime.</p>

<p><code>false &amp;&amp; bla</code><br>
Gets eliminated because of C/C++ lazy operand evaluation rule which is standardized with left to right order.<br>
The compiler generates no code so the machine has no overhead.</p>

<p><code>step(1.0, x) * texture2D(pic1, uv);</code></p>

<p>That will depend if x is coming from a uniform value, in which case the drivers will compile an adjustment of the shader (and put it in a combinator cache). At some point before starting to render.<br>
(this can cause hiccups in framerate when new uniform values are encountered that cause massive shader rebuild)</p>

<p>Now, if <code>x</code> is <strong>dependant</strong>, which means it comes from a previous calculation that comes from varying values or system values, the compiler will cut your expression in 2 parts, the <code>lerp</code> calculus and the <code>sample</code> call.<br>
It will move the sampling of the texture in the first instructions of the shader. (provided it's unconditional in the shader flow).<br>
So you're basically screwed when it's 0, you'll pay the sampling anyway.</p>

<p>In your case (0-2 wrt frag pos), I would recommend using <code>if (inrect(0,0,1,1))</code> because this is a low frequency "step" function, which means very good branch elimination in 3 quarters of the screen.</p>

CC BY-SA 3.0
2016-06-02T05:54:21.460Z
2016-06-02T05:54:21.460Z
v.oddou
<p>So I am trying to make my shader efficient by lowing the amount of texture lookups. If I had a line of code with something like.</p>

<pre><code>step(1.0, x) * texture2D(pic1, uv);
</code></pre>

<p>Where x is a value that ranges from 0 to 2 based on the fragment position.  Would the GPU see when step evaluates to 0 and thus not ever calculate texture2D? Or would it still lookup the texture because the 0 is not constant?</p>

<p>BTW I use the term "short circuit" because I have been told that is what happens when you have <code>false &amp;&amp; (bla)</code> the computer sees the false and ignores the right.</p>

<gpu>
GPU short circuit when multiply by 0?
J.Doe
# GPU short circuit when multiply by 0?

(Asked by: username_0 on 2016-06-02)

So I am trying to make my shader efficient by lowing the amount of texture lookups. If I had a line of code with something like.

```
step(1.0, x) * texture2D(pic1, uv);

```

Where x is a value that ranges from 0 to 2 based on the fragment position. Would the GPU see when step evaluates to 0 and thus not ever calculate texture2D? Or would it still lookup the texture because the 0 is not constant?

BTW I use the term "short circuit" because I have been told that is what happens when you have `false && (bla)` the computer sees the false and ignores the right.

**Tags:** gpu


---

## 1 answers

### Answer by username_1 on 2016-06-02. Score: 4 | Accepted answer

There is a difference between being able to determine value at compilation time and at runtime.

`false && bla`  
Gets eliminated because of C/C++ lazy operand evaluation rule which is standardized with left to right order.  
The compiler generates no code so the machine has no overhead.

`step(1.0, x) * texture2D(pic1, uv);`

That will depend if x is coming from a uniform value, in which case the drivers will compile an adjustment of the shader (and put it in a combinator cache). At some point before starting to render.  
(this can cause hiccups in framerate when new uniform values are encountered that cause massive shader rebuild)

Now, if `x` is **dependant**, which means it comes from a previous calculation that comes from varying values or system values, the compiler will cut your expression in 2 parts, the `lerp` calculus and the `sample` call.  
It will move the sampling of the texture in the first instructions of the shader. (provided it's unconditional in the shader flow).  
So you're basically screwed when it's 0, you'll pay the sampling anyway.

In your case (0-2 wrt frag pos), I would recommend using `if (inrect(0,0,1,1))` because this is a low frequency "step" function, which means very good branch elimination in 3 quarters of the screen.


---

