Rendering cubemap causes big lag spike at next gl command

SamCZ · December 14, 2020, 4:22pm

Hi, the problem is when I render cubemap for PBR IBL with 5 mipmap levels and after the render i call glFinish or glGetIntegerv big lag spike occured. The spike delay is longer the bigger the cubemap texture is.

For example 512x512 RGBA8_UNORM takes 5 seconds and 1024x1024 like 10s

I would not noticed this but the biggest problem is that this problem causes crash of the program on some computers.

Our three pc’s that we got home do not crash, but when I sent the game to my two friend, they cannot start the game, cause it crashed right after the next gl command was executed.

From what I tried the number of mipmaps do not matter, when I changed the value to 1 the same problem occured.

(And this weird thing happend, maybe it was just random, but its better if I mentions this: When one of my friends run the game for the first time, it not crashed. Before the cubemap was rendered one of my shaders (witch is not related to the cubemaps) did not compile because on his pc I needed to enable one of gl extensions in the shared. How do I know that the cubemap render was called after the shader error ? Because if it did not execute the other code it would crash because my render loop would access unknown memory.)

Is there some way to debug this other way then glGetError ? (This do not throw anything)

It would be gread help for me if someone does know why this could happend.

I cannot provide any debug information because the program just exits without any info and I cannot even provide some sample code, because its so much big rendering system that it would take so much time to edit it and it would be big file

Thank you for your time.

Silence · December 14, 2020, 4:39pm

You would not notice a hang for 5 to 10 seconds ?

Try this.

SamCZ · December 14, 2020, 4:57pm

Yeah because I tought its because the two big textures that I load before the rendering of the cubemaps.

Thank you i will the the debug mode.

SamCZ · December 14, 2020, 5:05pm

ok, so this is the output when i render the cubemaps

GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 10 (bound to GL_UNIFORM_BU
FFER_EXT, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 10 (bound to GL_UNIFORM_BU
FFER (0), usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 10 (bound to GL_UNIFORM_BU
FFER (0), usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 34 (bound to GL_TEXTURE_BU
FFER, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 35 (bound to GL_TEXTURE_BU
FFER, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 12 (bound to GL_UNIFORM_BU
FFER_EXT, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 12 (bound to GL_UNIFORM_BU
FFER (0), usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 12 (bound to GL_UNIFORM_BU
FFER (0), usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 13 (bound to GL_UNIFORM_BU
FFER (3), and GL_UNIFORM_BUFFER_EXT, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer objec
t operations.
GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 13 (bound to GL_UNIFORM_BU
FFER (3), and GL_UNIFORM_BUFFER_EXT, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer objec
t operations.
GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 13 (bound to GL_UNIFORM_BU
FFER (3), and GL_UNIFORM_BUFFER_EXT, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer objec
t operations.

GClements · December 14, 2020, 5:41pm

Is that output with a debug context?

If so, you’ll need to instrument your code; call glFinish then print a checkpoint identifier and timestamp. It seems like the IBL rendering is doing something extreme which is exceeding implementation limits on systems other than your own. Implementations are allowed to abort shaders which take too long to run; given the delays, that would be the first thing I’d check.

SamCZ · December 14, 2020, 6:52pm

Yes it is
This is the result

glFinish start
t operations.
GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 25 (bound to GL_UNIFORM_BU
FFER (0), and GL_UNIFORM_BUFFER_EXT, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer objec
t operations.
GL CALLBACK:  type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 29 (bound to GL_TEXTURE_BU
FFER, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buglFinish end
glFinish time: 8120.24ms

I tried to make the texture 2048x2048 and right after it crashed with exit code-1073740791 (0xC0000409)

I noticed that when the glFinish is happend my whole system is frozen.

SamCZ · December 14, 2020, 7:24pm

So i did some profiling gpu and this is some of the results

This is th cubemap idk what 61 revsions means but its hight number of textures

Silence · December 14, 2020, 8:59pm

Do you free your unused ressources ?

SamCZ · December 14, 2020, 10:34pm

This is done in Init and there are no resources to discard, result is the cubemap that I use in screenspace shared.

Silence · December 16, 2020, 4:00pm

Try to narrow things down until you find what is causing this hang.

Also check that your buffers (specially UBOs) don’t exceed the maximum size, and block number they could support. And ensure that the draw calls have all valid arguments (like start offset and number of vertices to draw), and that your VBO have valid data.

Dark_Photon · December 16, 2020, 8:13pm

5 seconds is outrageous.

From your debug output, it looks like you are running NV drivers.

Questions:

What OS/GPU/driver/driver version combinations do you see 5 second finish times?
What OS/GPU/driver/driver version combinations do you see a crash?
Are some of the crashes on Windoze?

If yes to #3, make sure you’re getting a HW accelerated context, and not a crappy Microsoft software-emulated OpenGL 1.1 context that doesn’t support much of anything. Asking for a window pixel format with the wrong combo of settings can land you with that context (e.g. 32-bit DOUBLE_BUFFER).

Also if yes to #3, you might find out whether these crashes are associated with a TDR. That can generate a multi-second freeze IIRC.