<p>Recently I've been looking at Vulkan, and one thing that I noticed is that the application is responsible for choosing which buffer to render to in the case of multiple buffering.</p>
<p>This got me thinking: since one of the benefits of multiple buffering is that the GPU can start rendering the next frame before the previous one is finished, is it worth it to create more offscreen buffers as well, like the G-Buffers or the HDR color buffers (especially in the older APIs like OpenGL and D3D11)? Will it have performance benefits? Is this common practice, or totally dumb?</p>

CC BY-SA 4.0
2020-07-01T15:59:47.170Z
I'm not sure I understand the question. In Vulkan, you can render to whatever renderable image you like, but you cannot *display* whatever image you like. You can only present images acquired from the presentation engine, and you can only render to them when the presentation engine says that you can (ie: when you have acquired it). So it's not really clear what you're asking about. Also, g-buffer and HDR images are pretty much never presentable images, so you'd have to create them anyway.
Nicol Bolas
CC BY-SA 4.0
2020-07-01T16:01:16.010Z
"*since one of the benefits of multiple buffering is that the GPU can start rendering the next frame before the previous one is finished*" That's only a benefit of *triple* (or more) buffering (and it's not even really the point of triple buffering). Standard double-buffering is all about not having to wait for an image to be finished being *displayed* before starting to render the next one.
Nicol Bolas
CC BY-SA 4.0
2020-07-01T19:42:47.143Z
Sorry for not being clear. My question is about whether there's a benefit to creating _multiple_ offscreen buffers to ping-pong between on consecutive frames, so frame n and frame n+1 render to different targets instead of the same ones. My reasoning was that for example frame 0 might still be reading from the G-buffer to calculate the lighting while frame 1 has already started rendering the G-buffer, so frame 1 has to wait for frame 0. I didn't find any resources on this however, so I feel like I'm missing something, I just don't know what it is.
Botond Máté
<opengl><vulkan><directx11><directx><direct3d>
OpenGL/D3D11 offscreen render multiple buffering
Botond Máté
# OpenGL/D3D11 offscreen render multiple buffering

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

Recently I've been looking at Vulkan, and one thing that I noticed is that the application is responsible for choosing which buffer to render to in the case of multiple buffering.

This got me thinking: since one of the benefits of multiple buffering is that the GPU can start rendering the next frame before the previous one is finished, is it worth it to create more offscreen buffers as well, like the G-Buffers or the HDR color buffers (especially in the older APIs like OpenGL and D3D11)? Will it have performance benefits? Is this common practice, or totally dumb?

**Tags:** opengl, vulkan, directx11, directx, direct3d

> **Comments:**
> **username_1**: I'm not sure I understand the question. In Vulkan, you can render to whatever renderable image you like, but you cannot *display* whatever image you like. You can only present images acquired from the presentation engine, and you can only render to them when the presentation engine says that you can (ie: when you have acquired it). So it's not really clear what you're asking about. Also, g-buffer and HDR images are pretty much never presentable images, so you'd have to create them anyway.  
> **username_1**: "*since one of the benefits of multiple buffering is that the GPU can start rendering the next frame before the previous one is finished*" That's only a benefit of *triple* (or more) buffering (and it's not even really the point of triple buffering). Standard double-buffering is all about not having to wait for an image to be finished being *displayed* before starting to render the next one.  
> **username_0**: Sorry for not being clear. My question is about whether there's a benefit to creating _multiple_ offscreen buffers to ping-pong between on consecutive frames, so frame n and frame n+1 render to different targets instead of the same ones. My reasoning was that for example frame 0 might still be reading from the G-buffer to calculate the lighting while frame 1 has already started rendering the G-buffer, so frame 1 has to wait for frame 0. I didn't find any resources on this however, so I feel like I'm missing something, I just don't know what it is.  

---

## 0 answers

