<p>I don't think your approach is viable for a variety of reasons.</p>

<ol>
<li><p>a GPU is heavily cache-dependent for performance. Pulling the same pixels over and over will just measure how fast a cache hit is. Sampling random pixels will only measure a cache miss. Neither are useful statistics. </p></li>
<li><p>each texture2d call will pull in multiple pixels to leverage that, in a fragment shader, neighbouring fragments will want neighbouring pixels.</p></li>
<li><p>The driver could optimize your shader to pull out the loop if it sees that each iteration does the exact same computation or if the computed result is not used.</p></li>
</ol>

CC BY-SA 3.0
2016-06-28T05:51:25.017Z
Nailed it. Of course, doing anything on a single fragment is massively wasteful anyway since you will have 31 or 63 other threads idling while it completes. If i was gonna  run a test like this to get at least a ballpark figure, i'd probably draw a full-window quad at say 1024^2, load up a bunch of different textures then sample each of them in turn until the framerate dropped, making sure to actually use the results like you say.
russ
CC BY-SA 3.0
2016-06-30T07:34:04.937Z
Thank you for this, giving up on that quest helped me realize how stupid it was to think I could take the amount of samples I do and somehow calculate a downsample size, and radius for a gaussian blur shader. Turns out it will work much better to just have predefined combinations of varying intensity and see which ones run at the desired fps.
J.Doe
CC BY-SA 3.0
2016-06-30T07:35:16.233Z
Are GPU compilers more innovative then CPU ones? I mean I have heard stuff about a gpu compiler recompiling because a uniform triggers a different part of an if statement and you speak of pulling out of the loop because the calculation is the same. I haven't heard of CPU's doing that.
J.Doe
CC BY-SA 3.0
2016-06-30T08:02:38.230Z
@J.Doe optimizers (for gpu and cpu) try to use every trick in the book however GPU optimizers know more about the program they are trying to optimize and what hardware it will be running on. The optimizations you mention are called [partial evaluation](https://en.wikipedia.org/wiki/Partial_evaluation) (with the uniforms as additional constant data) and [Loop-invariant code motion](https://en.wikipedia.org/wiki/Loop-invariant_code_motion)
ratchet freak
CC BY-SA 3.0
2016-06-27T14:06:45.213Z
2016-06-27T14:06:45.213Z
ratchet freak
<p>I am trying to programmatically figure out how many "texture2d " calls the gpu can make before the fps drops below 60fps.</p>

<p>My current way of doing this is to have a fragment shader with a for loop that will run a specified number of times based on a passed in uniform. So each frame the for loop will run more times, each time sampling the texture more times.</p>

<p>Then on the cpu I can monitor the fps and see when it drops.</p>

<p>My problem is if this shader runs on more then one pixel then the test is worth nothing.</p>

<p>How can I ensure from the cpu code and vertex shader that the fragment program only runs once?</p>

CC BY-SA 3.0
2016-06-27T10:00:28.337Z
I don't think that is going to measure what you think it will. Not to mention fragment shaders run (at least) in a 2x2 block for each fragment.
ratchet freak
CC BY-SA 3.0
2016-06-27T10:12:39.550Z
@ratchetfreak 2x2 block per fragment even without multisampling? Why?
Ruslan
CC BY-SA 3.0
2016-06-27T11:09:12.183Z
@Ruslan: fragments are treated as 2x2 blocs so the derivatives can be evaluated.
Julien Guertault
<gpu><fragment-shader>
How to ensure a fragment shader only runs once
J.Doe
# How to ensure a fragment shader only runs once

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

I am trying to programmatically figure out how many "texture2d " calls the gpu can make before the fps drops below 60fps.

My current way of doing this is to have a fragment shader with a for loop that will run a specified number of times based on a passed in uniform. So each frame the for loop will run more times, each time sampling the texture more times.

Then on the cpu I can monitor the fps and see when it drops.

My problem is if this shader runs on more then one pixel then the test is worth nothing.

How can I ensure from the cpu code and vertex shader that the fragment program only runs once?

**Tags:** gpu, fragment-shader

> **Comments:**
> **username_1**: I don't think that is going to measure what you think it will. Not to mention fragment shaders run (at least) in a 2x2 block for each fragment.  
> **username_2**: @username_1 2x2 block per fragment even without multisampling? Why?  
> **username_3**: @username_2: fragments are treated as 2x2 blocs so the derivatives can be evaluated.  

---

## 1 answers

### Answer by username_1 on 2016-06-27. Score: 6 | Accepted answer

I don't think your approach is viable for a variety of reasons.

1. a GPU is heavily cache-dependent for performance. Pulling the same pixels over and over will just measure how fast a cache hit is. Sampling random pixels will only measure a cache miss. Neither are useful statistics.
2. each texture2d call will pull in multiple pixels to leverage that, in a fragment shader, neighbouring fragments will want neighbouring pixels.
3. The driver could optimize your shader to pull out the loop if it sees that each iteration does the exact same computation or if the computed result is not used.

> **Comments:**
> **username_4**: Nailed it. Of course, doing anything on a single fragment is massively wasteful anyway since you will have 31 or 63 other threads idling while it completes. If i was gonna  run a test like this to get at least a ballpark figure, i'd probably draw a full-window quad at say 1024^2, load up a bunch of different textures then sample each of them in turn until the framerate dropped, making sure to actually use the results like you say.  
> **username_0**: Thank you for this, giving up on that quest helped me realize how stupid it was to think I could take the amount of samples I do and somehow calculate a downsample size, and radius for a gaussian blur shader. Turns out it will work much better to just have predefined combinations of varying intensity and see which ones run at the desired fps.  
> **username_0**: Are GPU compilers more innovative then CPU ones? I mean I have heard stuff about a gpu compiler recompiling because a uniform triggers a different part of an if statement and you speak of pulling out of the loop because the calculation is the same. I haven't heard of CPU's doing that.  
> **username_1**: @username_0 optimizers (for gpu and cpu) try to use every trick in the book however GPU optimizers know more about the program they are trying to optimize and what hardware it will be running on. The optimizations you mention are called [partial evaluation](https://en.wikipedia.org/wiki/Partial_evaluation) (with the uniforms as additional constant data) and [Loop-invariant code motion](https://en.wikipedia.org/wiki/Loop-invariant_code_motion)  

---

