I'm adding dynamic cubemap reflections and image-based ambient lighting to my engine (using OpenGL) and have encountered a problem that I'm not sure how to handle. I can render the scene 6 times to a cube map successfully, and use the cube map for reflections.

However, when I try to generate mipmaps for the reflection cube map using glGenerateMipmap(), it is unbelievably slow (like 30-100ms for a tiny 8 pixel cube map). In the other places I am calling glGenerateMipmap() every frame, such as on a copy of the main framebuffer, it is about 1000 times faster. Surely I am doing something wrong to get such bad performance.

My rendering pipeline is like this:

• I create an FBO with a color cube map and depth cube map bound. This is done once on the first frame, and the FBO+maps are reused each frame.
• When rendering reflections, I first bind the FBO, then render the scene 6 times, each time I calll glFramebufferTexture2D() to switch to the right cube map face. Afterwards all faces are done, I unbind the FBO.
• Then I generate mipmaps for the new cube map contents using glGenerateMipmap().
• For testing purposes I am not even using the cube map for any further rendering.

These are the things I have tried to resolve this:

• I tried unbinding the texture from the FBO before calling glGenerateMipmap(), with no effect.
• I tried creating multiple FBO+map assemblies and rotating between them on each frame, with no effect.
• If I never bind the FBO for rendering, then glGenerateMipmap() is fast (though it has garbage image).
• If I bind the FBO for rendering but don't draw anything, mip generation is fast. Even adding glClear() makes it slow again.
• Calling glGenerateMipmap() again after the first time is fast.

My feeling is that this is somehow related to the texture being bound to an FBO at the same time, though there are lots of other places (e.g. shadow maps, water refraction pass) where I use a texture immediately after rendering to it in an FBO, without any problems. For instance, for refraction, I blit the main framebuffer to another texture (also bound to an FBO), and can generate mipmaps very quickly (30us). The only thing particular to this situation is that the texture is a cube map, and that I'm rendering into it rather than calling glBlitFramebuffer().

One potential workaround is to render into a 2D texture instead, then glBlitFramebuffer() the 2D texture into the cube map faces after rendering. I haven't tried this and would like to avoid it.

Does anyone have any ideas or pointers for how to resolve this performance issue?

That's a whole lot of jibberish that completely ignores the question of the OP, with some bad advice thrown in:

alice wolfraider said:
all game programmers and even advanced game users measure performance in FPS, not in micro-seconds or anything else that is

It's much better to measure performance in time units (s, ms, us) than in inverse time units (FPS) because there is a linear relationship, making comparisons more sensible. See article: FPS Versus Frame Time. How do you measure the “FPS” of a certain part of a frame? It just doesn't make sense. For this reason, almost all reputable academic papers use time units.

Its entirely possible that glGenerateMipmap is doing work client side( host) instead of server-side( GPU) to generate the mip maps. If this is indeed the case there will be a sync point to the server-host transfer( GPU-CPU) and the subsequent host-server ( CPU-GPU) transfer of the generated mips. I still can't think of the way to validate this at the moment, but have you tried this.
1. Create your cube map and allocate all the mipmaps up front.
2. Each frame render into each cubemap face as before.
3. For each cubemap face for mip level ≥ 1, bind to a FBO.
4. Use a simple ‘texture copy’ shader ( full screen quad) to draw into the render target, using the level 0 face as the source.
This would result in a mip-map downsampling as long a you set up your viewports correctly. The only caveat is that the your
source and destination will be same texture, albeit different mip-levels being read from and written to. This I believe is valid GL behavior.

Its a little more work, but it does keep all the work GPU side .

Thanks for the idea @cgrant. I think you are right about the CPU-GPU sync.

I tested out the same code on another machine with different GPU (Nvidia 1070) and don't observe any slowness there, so I'm thinking it is something specific to the GPU or driver on my main development machine. It's an old integrated intel GPU (HD 4600).

The likely storyline is that by calling glGenerateMipmap() I introduce a sync point, causing the GPU to have to execute all buffered commands up to that point. Since the GPU is slow this takes a long time (it's already running at only 10FPS without any cubemap stuff). This shows up in my CPU-side profiling as spending tons of time in glGenerateMipmap(), but I think it is just an artifact of how I measure time. If I measure the whole frame time it doesn't change that much when calling glGenerateMipmap().

cgrant said:
4. Use a simple ‘texture copy’ shader ( full screen quad) to draw into the render target, using the level 0 face as the source. This would result in a mip-map downsampling as long a you set up your viewports correctly.

The approach will miss to filter other faces of the cube on edges and corners, likely causing visible seams in reflections.
If glGenerateMipmap() can't be used, you likely have to care about this detail yourself. (Not sure if the GL function is specified to implement proper prefiltering anyway.)

Maybe using GPU profiling tools would give more insight on what's happening.

EDIT:

Oops, i think i'm wrong with my prefiltering worries. IIRC, there is no need to include other cube faces when generating mip maps. We only need to enable cube map filtering when sampling the texture afterwards.

JoeJ said:
there is no need to include other cube faces when generating mip maps

I think there is, if you want it to be seamless. That's what glEnable( GL_TEXTURE_CUBE_MAP_SEAMLESS ) is supposed to do. Without it you only get filtering within each face, which does produce visible seams at the cube edges. Ideally you would downsample the cube map using filtering over a solid angle, which would include neighboring faces at the borders. It would be something similar to what is done in this tutorial to generate irradiance cube maps (but without the blurring).

@alice wolfraider I think you need to sit down and reconsider your communication style. I understand that English may not be your native language, but it's important to know the limits of your own abilities and knowledge. Your posts are incoherent and largely irrelevant to this thread. You talk down to people with more experience, and much of the advice you offer is plainly bad advice. Please come down off Mount Dunning-Kruger.

I'm on the fence whether you are a LLM or not. If so, you need to get better training data.

Aressera said:
Ideally you would downsample the cube map using filtering over a solid angle, which would include neighboring faces at the borders. It would be something similar to what is done in this tutorial to generate irradiance cube maps (but without the blurring).

Yeah, that's exactly what i had in mind when i've thought mip generation would need access to all faces.

I wonder if such prefiltering is done for reflection probes too, not only for diffuse. I guess no, since we would need multiple cube maps for multiple cone angles. Likely it's better to take multiple samples instead.