<p>The compositor in the OS wants to run at a consistent 60 FPS whatever rate your application runs at. If there were a single framebuffer for your application, then you might end up writing to it at the same time the compositor or overlay hardware wants to read from it to put it into the final frame. This would cause tearing. (Tearing could be avoided with a lock, but then the compositor might get stuck waiting for your frame to finish, which would also stop the user using the system GUI to get out of your slow/hanging app.)</p>

<p>This is pretty much the same reason double buffering is used when you're drawing to a monitor directly, just earlier in the pipeline.</p>

<p>This doesn't <em>usually</em> apply for processing within your application, because generally everything has to run at the same rate, and you can't run multiple stages in parallel. Say you draw some 3D stuff and then use a full-screen fragment shader to add some film grain and vignetting. It doesn't help if your full-screen shader can run faster than the 3D work, because you'll just be processing the same intermediate frames again.</p>

<p>I can think of two situations really where it might help. The first is if it's not a post-process but something different, such as if you have a GUI or HUD that you want to run at full frame-rate even if you get frame drops in the main content. (This is the case the OS's window compositor falls into.)</p>

<p>The second is if you can run the multiple stages of your processing pipeline in parallel, e.g. on multiple GPUs. That way, you can start rendering the next 3D frame while the full-screen shader is vignetting your previous frame. You'd have to know your hardware pretty well to split the work appropriately. On something like a gaming PC or graphics workstation that's using SLI to use multiple GPUs, you might find your parallel processing is slower because the workload is unbalanced and one GPU is idling a lot.</p>

CC BY-SA 3.0
2018-01-07T23:25:01.763Z
2018-01-07T23:25:01.763Z
Dan Hulme
<p>At least on iOS every frame you are likely to get a completely new texture that you need to draw to due to the OS switching between a couple textures each frame.</p>

<p>My question is essentially if the OS feels the need to use multiple textures should we also be using multiple textures for some reason when doing full screen post processing? Is there ever a time where switching between off screen textures can improve performance? </p>

<texture><frame-buffer>
If the OS uses a frame-buffer with potentially different textures being displayed each frame why dont we?
J.Doe
# If the OS uses a frame-buffer with potentially different textures being displayed each frame why dont we?

(Asked by: username_0 on 2018-01-07)

At least on iOS every frame you are likely to get a completely new texture that you need to draw to due to the OS switching between a couple textures each frame.

My question is essentially if the OS feels the need to use multiple textures should we also be using multiple textures for some reason when doing full screen post processing? Is there ever a time where switching between off screen textures can improve performance?

**Tags:** texture, frame-buffer


---

## 1 answers

### Answer by username_1 on 2018-01-07. Score: 3

The compositor in the OS wants to run at a consistent 60 FPS whatever rate your application runs at. If there were a single framebuffer for your application, then you might end up writing to it at the same time the compositor or overlay hardware wants to read from it to put it into the final frame. This would cause tearing. (Tearing could be avoided with a lock, but then the compositor might get stuck waiting for your frame to finish, which would also stop the user using the system GUI to get out of your slow/hanging app.)

This is pretty much the same reason double buffering is used when you're drawing to a monitor directly, just earlier in the pipeline.

This doesn't *usually* apply for processing within your application, because generally everything has to run at the same rate, and you can't run multiple stages in parallel. Say you draw some 3D stuff and then use a full-screen fragment shader to add some film grain and vignetting. It doesn't help if your full-screen shader can run faster than the 3D work, because you'll just be processing the same intermediate frames again.

I can think of two situations really where it might help. The first is if it's not a post-process but something different, such as if you have a GUI or HUD that you want to run at full frame-rate even if you get frame drops in the main content. (This is the case the OS's window compositor falls into.)

The second is if you can run the multiple stages of your processing pipeline in parallel, e.g. on multiple GPUs. That way, you can start rendering the next 3D frame while the full-screen shader is vignetting your previous frame. You'd have to know your hardware pretty well to split the work appropriately. On something like a gaming PC or graphics workstation that's using SLI to use multiple GPUs, you might find your parallel processing is slower because the workload is unbalanced and one GPU is idling a lot.


---

