<p>You should always profile to determine where your slowdown occurs. From your question, it's unclear whether your work is CPU bound or GPU bound.</p>

<blockquote>
  <p>But I don't really understand what is does: Does this render a multiple time the same mesh ? different mesh but with one shader ? different mesh with different shader but just with low CPU overhead ?</p>
</blockquote>

<p>The <code>glMultiDraw*</code> draw commands are for allowing you to render multiple objects in one draw call. In terms of OpenGL 3.0 and later, this means that you could specify a VBO holding a bunch of objects and use <code>glMultiDraw*</code> to render them. You would use this with the same shader. If you want to render the same object multiple times, then using something such as <a href="https://www.opengl.org/wiki/Vertex_Rendering#Instancing" rel="nofollow noreferrer">instancing</a> would be a good solution.</p>

<p>This all concerns draw calls though. If you have one million triangles for only a few meshes, you won't see a massive speedup with rendering. You didn't specify your framebuffer size, but if it's small enough, you can cause severe overdraw from many small triangles. If the images are really that small, maybe you should think about adding an LOD system or use lower polygon meshes and tessellate.</p>

<blockquote>
  <p>trying to reduce the render time while rendering multiple time the same mesh in "Bounces" using the same technique than this</p>
</blockquote>

<p><a href="https://docs.google.com/presentation/d/19x9XDjUvkW_9gsfsMQzt3hZbRNziVsoCEHOn4AercAc/edit#slide=id.p" rel="nofollow noreferrer">Stereo instanced rendering</a> is specifically a technique for VR. It relies on the assumption that the scene is pretty much identical in each eye, and so it uses instancing to render to two sides of the screen at once. However, if your bounces render similar geometry, then you may be able to render multiple bounces onto a larger framebuffer provided that the bounces are independent. There is potential for speedup from avoiding framebuffer switching (which is a rather expensive process).</p>

<p>In newer OpenGL versions (4.0 and above), there is added support for <a href="https://www.opengl.org/wiki/Vertex_Rendering#Indirect_rendering" rel="nofollow noreferrer">indirect rendering</a>, which allows you to determine parameters through GPU computing, but it's unclear if that will help you in this case.</p>

CC BY-SA 3.0
2016-11-20T18:36:59.713Z
My CPU load reach rarely more than 30% when I'm bellow 20FPS so I am GPU bound. For my glMultiDraw* problem for now I use matrices to move my objects (the UpdateTransformUniform() call) is this possible to link glMultiDrawElements to a buffer of uniform or something like this?  For my buffers, my final buffers are 4 1920x1080 (I'm using deffered rendering) and my bounces are 4 64x64 (will be replaced to 1 64x64 soon). For the algorythm: should I loop over my bounces in every mesh using instances rendering or loop glMultiDraw my mesh for every bounces.
newin
CC BY-SA 3.0
2016-11-21T05:31:32.107Z
Actually, I think this is what you would want if you're using uniform transformation matrices: glDrawElementsInstancedBaseVertexBaseInstance (OpenGL 4.2). Here's more info about it: http://www.gamedev.net/topic/682969-minimizing-draw-calls-and-passing-transformmaterial-data-to-a-shader-in-opengl-3x/
aces
CC BY-SA 3.0
2016-11-21T05:41:44.900Z
I ask a similar question to the once you are asking here: http://computergraphics.stackexchange.com/questions/4241/instanced-stereo-rendering-vs-multiple-command-buffers
aces
CC BY-SA 3.0
2016-11-21T05:42:22.317Z
Either way, it's not going to make a huge difference if your performance limited by the GPU. With a 64x64 grid, you are going to be doing a lot of overdrawing, even for a deferred renderer, so you should start optimizing there. But in terms of your followup question, I would go through that slideshow I linked and see if that can help you in your situation (extending it to a grid rather than two screens).
aces
CC BY-SA 3.0
2016-11-25T20:09:15.917Z
Okay I'm almost good, last question: it looks like the stereo instanced rendering seems to use 1 render target split in 2 but I have multiple FBO. I cannot find a way to use instances across multiple FBO, is this possible, if yes how ?
newin
CC BY-SA 3.0
2016-11-27T22:35:53.753Z
Take this with a grain of salt because I haven't implemented it before (and you should probably post a separate question about this specific technique as I'm sure some have and can give better advice). From my understanding, the idea is to scale each instance's NDCs down depending on the side you are rendering and then set the clip planes in a shader. This should be able to be generalized to your approach (instead of two sides, have a grid). You need to pass a region number (side) to each instance.
aces
CC BY-SA 3.0
2016-11-19T07:06:00.010Z
2016-11-19T07:06:00.010Z
aces
<p>A common approach for real-time radiosity in games is to assume static geometry, which can be used to pre-calculate visible surfels (position, albedo, normal) for a point in space (light probe). This approach avoids the need for run-time rasterization of the geometry for different viewpoints. The surfels can be then dynamically re-lit in run-time and used to gather luminance for the probe, which is used to approximate the indirect illumination.</p>

CC BY-SA 3.0
2016-11-20T02:14:01.213Z
2016-11-20T02:19:53.937Z
2016-11-20T02:19:53.937Z
JarkkoL
<p>I want to experiment with some new stuff about modern rendering techniques and in that way I'm trying to implement a custom GI (somewhere between pathtracing and instant radiosity).
My scene is a bit less than 1,000,000 tris and my algorithm requires to render the same scene <em>a lot</em> of times into different tiny textures (let's call them "bounces").</p>

<p>I've began my implementation in a naive way so I rapidly ran into some performance problems:<br>
With my 1TFlops laptop GPU I can render my 1M poly scene I can have 200 "bounces" before dropping bellow 30FPS which is far from enough.</p>

<p>My "naive" algorithm looks like this in pseudo code:</p>

<pre><code>for (unsigned int i = 0; i &lt; res ; ++i) {
  UpdateCameraUniform(i);
  glBindFramebuffer(GL_FRAMEBUFFER, BounceFbo[i]);
  glDrawBuffers(1, renderBuffer[i]);
  for (Mesh&amp; m : Scene) {
    m.render();
  }
}
</code></pre>

<p>with</p>

<pre><code>Mesh::render() {
UpdateTransformUniform();
glBindVertexArray(_vao);
glBindBuffer(GL_ARRAY_BUFFER, _vbo);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, _ebo);
glDrawElements(GL_TRIANGLES, size, GL_UNSIGNED_INT, 0);
}
</code></pre>

<p>The full code is <a href="https://github.com/newincpp/GLnewin/tree/master/GLnewin" rel="nofollow noreferrer">here</a> (the depot is really messy for now...).</p>

<p>I need to find a new strategy to render my scene so I searched what I could do.<br>
I think I have 2 strategies:</p>

<ol>
<li><p>Trying to reduce the number (or the performance) of my drawcalls. It seems that there is some magic function like glMultiDraw* (I've found it in a post on "OpenGL superbible" <a href="http://www.openglsuperbible.com/2013/10/16/the-road-to-one-million-draws/" rel="nofollow noreferrer">here</a>). But I don't really understand what this does:</p>

<ul>
<li>Does this render multiple times the same mesh?</li>
<li>Different mesh but with one shader?</li>
<li>Different mesh with different shader but just with low CPU overhead?</li>
</ul></li>
<li><p>Trying to reduce the render time while rendering multiple times the same mesh in "Bounces" using the same technique as <a href="https://www.youtube.com/watch?v=nmajnglJeyE" rel="nofollow noreferrer">this</a> but I have absolutely no idea how it works or even if it can apply to me...</p></li>
</ol>

<p>Obviously I am open to any other suggestions.</p>

<p>Edit: I can reach 200 "bounces" not 35</p>

CC BY-SA 3.0
2016-11-20T17:50:45.323Z
@trichoplax yes but my reputation was not high enough to put more than 2 link so I changed it and then forgot to change my sentence sorry =/ I will fix it
newin
CC BY-SA 3.0
2016-11-22T17:47:01.777Z
I (finally) fixed it
newin
<opengl><performance>
How can I improve the performance of my custom Global Illumination approach?
newin
# How can I improve the performance of my custom Global Illumination approach?

(Asked by: username_0 on 2016-11-18)

I want to experiment with some new stuff about modern rendering techniques and in that way I'm trying to implement a custom GI (somewhere between pathtracing and instant radiosity).
My scene is a bit less than 1,000,000 tris and my algorithm requires to render the same scene *a lot* of times into different tiny textures (let's call them "bounces").

I've began my implementation in a naive way so I rapidly ran into some performance problems:  
With my 1TFlops laptop GPU I can render my 1M poly scene I can have 200 "bounces" before dropping bellow 30FPS which is far from enough.

My "naive" algorithm looks like this in pseudo code:

```
for (unsigned int i = 0; i < res ; ++i) {
  UpdateCameraUniform(i);
  glBindFramebuffer(GL_FRAMEBUFFER, BounceFbo[i]);
  glDrawBuffers(1, renderBuffer[i]);
  for (Mesh& m : Scene) {
    m.render();
  }
}

```

with

```
Mesh::render() {
UpdateTransformUniform();
glBindVertexArray(_vao);
glBindBuffer(GL_ARRAY_BUFFER, _vbo);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, _ebo);
glDrawElements(GL_TRIANGLES, size, GL_UNSIGNED_INT, 0);
}

```

The full code is [here](https://github.com/newincpp/GLnewin/tree/master/GLnewin) (the depot is really messy for now...).

I need to find a new strategy to render my scene so I searched what I could do.  
I think I have 2 strategies:

1. Trying to reduce the number (or the performance) of my drawcalls. It seems that there is some magic function like glMultiDraw\* (I've found it in a post on "OpenGL superbible" [here](http://www.openglsuperbible.com/2013/10/16/the-road-to-one-million-draws/)). But I don't really understand what this does:

   * Does this render multiple times the same mesh?
   * Different mesh but with one shader?
   * Different mesh with different shader but just with low CPU overhead?
2. Trying to reduce the render time while rendering multiple times the same mesh in "Bounces" using the same technique as [this](https://www.youtube.com/watch?v=nmajnglJeyE) but I have absolutely no idea how it works or even if it can apply to me...

Obviously I am open to any other suggestions.

Edit: I can reach 200 "bounces" not 35

**Tags:** opengl, performance

> **Comments:**
> **username_0**: @trichoplax yes but my reputation was not high enough to put more than 2 link so I changed it and then forgot to change my sentence sorry =/ I will fix it  
> **username_0**: I (finally) fixed it  

---

## 2 answers

### Answer by username_1 on 2016-11-19. Score: 2 | Accepted answer

You should always profile to determine where your slowdown occurs. From your question, it's unclear whether your work is CPU bound or GPU bound.

> But I don't really understand what is does: Does this render a multiple time the same mesh ? different mesh but with one shader ? different mesh with different shader but just with low CPU overhead ?

The `glMultiDraw*` draw commands are for allowing you to render multiple objects in one draw call. In terms of OpenGL 3.0 and later, this means that you could specify a VBO holding a bunch of objects and use `glMultiDraw*` to render them. You would use this with the same shader. If you want to render the same object multiple times, then using something such as [instancing](https://www.opengl.org/wiki/Vertex_Rendering#Instancing) would be a good solution.

This all concerns draw calls though. If you have one million triangles for only a few meshes, you won't see a massive speedup with rendering. You didn't specify your framebuffer size, but if it's small enough, you can cause severe overdraw from many small triangles. If the images are really that small, maybe you should think about adding an LOD system or use lower polygon meshes and tessellate.

> trying to reduce the render time while rendering multiple time the same mesh in "Bounces" using the same technique than this

[Stereo instanced rendering](https://docs.google.com/presentation/d/19x9XDjUvkW_9gsfsMQzt3hZbRNziVsoCEHOn4AercAc/edit#slide=id.p) is specifically a technique for VR. It relies on the assumption that the scene is pretty much identical in each eye, and so it uses instancing to render to two sides of the screen at once. However, if your bounces render similar geometry, then you may be able to render multiple bounces onto a larger framebuffer provided that the bounces are independent. There is potential for speedup from avoiding framebuffer switching (which is a rather expensive process).

In newer OpenGL versions (4.0 and above), there is added support for [indirect rendering](https://www.opengl.org/wiki/Vertex_Rendering#Indirect_rendering), which allows you to determine parameters through GPU computing, but it's unclear if that will help you in this case.

> **Comments:**
> **username_0**: My CPU load reach rarely more than 30% when I'm bellow 20FPS so I am GPU bound. For my glMultiDraw* problem for now I use matrices to move my objects (the UpdateTransformUniform() call) is this possible to link glMultiDrawElements to a buffer of uniform or something like this?  For my buffers, my final buffers are 4 1920x1080 (I'm using deffered rendering) and my bounces are 4 64x64 (will be replaced to 1 64x64 soon). For the algorythm: should I loop over my bounces in every mesh using instances rendering or loop glMultiDraw my mesh for every bounces.  
> **username_1**: Actually, I think this is what you would want if you're using uniform transformation matrices: glDrawElementsInstancedBaseVertexBaseInstance (OpenGL 4.2). Here's more info about it: http://www.gamedev.net/topic/682969-minimizing-draw-calls-and-passing-transformmaterial-data-to-a-shader-in-opengl-3x/  
> **username_1**: I ask a similar question to the once you are asking here: http://computergraphics.stackexchange.com/questions/4241/instanced-stereo-rendering-vs-multiple-command-buffers  
> **username_1**: Either way, it's not going to make a huge difference if your performance limited by the GPU. With a 64x64 grid, you are going to be doing a lot of overdrawing, even for a deferred renderer, so you should start optimizing there. But in terms of your followup question, I would go through that slideshow I linked and see if that can help you in your situation (extending it to a grid rather than two screens).  
> **username_0**: Okay I'm almost good, last question: it looks like the stereo instanced rendering seems to use 1 render target split in 2 but I have multiple FBO. I cannot find a way to use instances across multiple FBO, is this possible, if yes how ?  
> **username_1**: Take this with a grain of salt because I haven't implemented it before (and you should probably post a separate question about this specific technique as I'm sure some have and can give better advice). From my understanding, the idea is to scale each instance's NDCs down depending on the side you are rendering and then set the clip planes in a shader. This should be able to be generalized to your approach (instead of two sides, have a grid). You need to pass a region number (side) to each instance.  

---

### Answer by username_2 on 2016-11-20. Score: 0

A common approach for real-time radiosity in games is to assume static geometry, which can be used to pre-calculate visible surfels (position, albedo, normal) for a point in space (light probe). This approach avoids the need for run-time rasterization of the geometry for different viewpoints. The surfels can be then dynamically re-lit in run-time and used to gather luminance for the probe, which is used to approximate the indirect illumination.


---

