"VBO discarded". Most part of VBO overridden with 0 (zeroes).

OpenGL OpenGL: Advanced Coding
1

I am experiencing very strange behavior which feels like a driver bug.

When my machine is loaded and (especially!) when I have opened YouTube stream this happens:
[ul]
[li]my game freezes for 1-5 seconds
[/li][li]it restores but with one or two “corrupted” VBOs
[/li][li]strange messages in the OpenGL Debug (excerpt below)
[/li][li]very long glFinish() - in NVidia NSight Log
[/li][/ul]
After it restores from freeze, visually I just see that some of sprites are gone.
Using RenderDoc I discovered that some of VBOs are “corrupted” - most part of them are overridden with 0 (zeroes). Strange thing - first 200-500 bytes are safe.
Corrupted VBOs are always same. So everytime it happens I see same sprites missing.
If I try to re-upload “corrupted” VBOs (glBufferSubData) using special hot-key - it works - all sprites are visible again.

I can’t understand the meaning of messages in the OpenGL Debug, but it looks like all(!) VBOs were freed and then allocated again for some reason…
The most strange message is: “Buffer usage warning: Discarding a video memory only buffer object. The data store will be reallocated on next usage of the buffer object.”
Why to discard VBO anyway ??
What is “video memory only buffer object” ??

This is very unexpected, considering that I am using very very basic OpenGL API… I have only 1 thread and I am not using VBO mapping.

The only clue I have is that this have something related to lack of free VRAM - according to GPU-Z, almost all of GPU memory (3Gb) is used.

Any advice what can cause such a behavior and what approach I should stick to discover the reason?

Windows 8.1
NVidia card: GeForce GTX 780 Ti/PCIe/SSE2
NVidia driver: 391.01
OpenGL: 4.6, Compatibility profile

[14:54:57] glDebug: (SOURCE_API, TYPE_OTHER, 131204, SEVERITY_LOW): Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
[14:54:57] glDebug: (SOURCE_API, TYPE_OTHER, 131204, SEVERITY_LOW): Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
[14:54:57] glDebug: (SOURCE_API, TYPE_OTHER, 131184, SEVERITY_LOW): Buffer info: 
Total VBO memory usage in the system:
 memType: SYSHEAP, 0 bytes Allocated, numAllocations: 0.
 memType: VID, 9.43 Mb Allocated, numAllocations: 25.
 memType: DMA_CACHED, 0 bytes Allocated, numAllocations: 0.
 memType: MALLOC, 214.61 Kb Allocated, numAllocations: 24.
 memType: PAGED_AND_MAPPED, 7.05 Mb Allocated, numAllocations: 19.
 memType: PAGED, 11.90 Mb Allocated, numAllocations: 25.

[14:54:57] glDebug: (SOURCE_API, TYPE_OTHER, 131204, SEVERITY_LOW): Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
[14:54:57] glDebug: (SOURCE_API, TYPE_OTHER, 131204, SEVERITY_LOW): Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
[14:54:57] glDebug: (SOURCE_API, TYPE_OTHER, 131184, SEVERITY_LOW): Buffer info: 
Total VBO memory usage in the system:
 memType: SYSHEAP, 0 bytes Allocated, numAllocations: 0.
 memType: VID, 9.43 Mb Allocated, numAllocations: 25.
 memType: DMA_CACHED, 0 bytes Allocated, numAllocations: 0.
 memType: MALLOC, 214.61 Kb Allocated, numAllocations: 24.
 memType: PAGED_AND_MAPPED, 7.05 Mb Allocated, numAllocations: 19.
 memType: PAGED, 11.90 Mb Allocated, numAllocations: 25.

[14:54:57] glDebug: (SOURCE_API, TYPE_OTHER, 131204, SEVERITY_LOW): Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (1) with size:, 1.77 Mb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (2) with size:, 1.77 Mb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (3) with size:, 908.37 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131188, SEVERITY_LOW): Buffer usage warning: Discarding a video memory only buffer object. The data store will be reallocated on next usage of the buffer object.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (4) with size:, 242.81 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (5) with size:, 242.81 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131188, SEVERITY_LOW): Buffer usage warning: Discarding a video memory only buffer object. The data store will be reallocated on next usage of the buffer object.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (6) with size:, 121.41 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (7) with size:, 234.38 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (8) with size:, 234.38 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (9) with size:, 117.19 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131188, SEVERITY_LOW): Buffer usage warning: Discarding a video memory only buffer object. The data store will be reallocated on next usage of the buffer object.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (10) with size:, 187.50 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (11) with size:, 187.50 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (12) with size:, 93.75 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (13) with size:, 93.75 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (14) with size:, 93.75 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (15) with size:, 46.88 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131188, SEVERITY_LOW): Buffer usage warning: Discarding a video memory only buffer object. The data store will be reallocated on next usage of the buffer object.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (16) with size:, 432 bytes from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131188, SEVERITY_LOW): Buffer usage warning: Discarding a video memory only buffer object. The data store will be reallocated on next usage of the buffer object.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (17) with size:, 432 bytes from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131188, SEVERITY_LOW): Buffer usage warning: Discarding a video memory only buffer object. The data store will be reallocated on next usage of the buffer object.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (18) with size:, 216 bytes from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131188, SEVERITY_LOW): Buffer usage warning: Discarding a video memory only buffer object. The data store will be reallocated on next usage of the buffer object.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (19) with size:, 468.75 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131188, SEVERITY_LOW): Buffer usage warning: Discarding a video memory only buffer object. The data store will be reallocated on next usage of the buffer object.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (20) with size:, 468.75 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131188, SEVERITY_LOW): Buffer usage warning: Discarding a video memory only buffer object. The data store will be reallocated on next usage of the buffer object.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (21) with size:, 234.38 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (22) with size:, 682.59 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131188, SEVERITY_LOW): Buffer usage warning: Discarding a video memory only buffer object. The data store will be reallocated on next usage of the buffer object.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (23) with size:, 455.06 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (24) with size:, 227.53 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Freeing VBO (25) with size:, 682.59 Kb from location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131204, SEVERITY_LOW): Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131204, SEVERITY_LOW): Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131184, SEVERITY_LOW): Buffer info: 
Total VBO memory usage in the system:
 memType: SYSHEAP, 0 bytes Allocated, numAllocations: 0.
 memType: VID, 0 bytes Allocated, numAllocations: 0.
 memType: DMA_CACHED, 0 bytes Allocated, numAllocations: 0.
 memType: MALLOC, 276.30 Kb Allocated, numAllocations: 38.
 memType: PAGED_AND_MAPPED, 18.55 Mb Allocated, numAllocations: 26.
 memType: PAGED, 23.40 Mb Allocated, numAllocations: 32.

[14:55:03] WARNING: [FPSdrop]: frame: 1929, dTicks = 5395 (0.19 FPS), VM: 93712384 - 93712384 = 0, PF: 226647 - 226647 = 0, T: 37023, 37024, 42418 (1, 5394)
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131204, SEVERITY_LOW): Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (4) with size:, 242.81 Kb to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 4 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 4 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 4 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (6) with size:, 121.41 Kb to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 6 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 6 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 6 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (1) with size:, 1.77 Mb to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 1 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (0), usage hint is GL_STATIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 1 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (0), usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (2) with size:, 1.77 Mb to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 2 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (1), usage hint is GL_STATIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 2 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (1), usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (3) with size:, 908.37 Kb to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 3 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (2), usage hint is GL_STATIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 3 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (2), usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (5) with size:, 242.81 Kb to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 5 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (1), usage hint is GL_DYNAMIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 5 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (1), usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (10) with size:, 187.50 Kb to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 10 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (0), usage hint is GL_DYNAMIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 10 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (0), usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 10 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (0), usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (11) with size:, 187.50 Kb to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 11 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (1), usage hint is GL_DYNAMIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 11 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (1), usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (12) with size:, 93.75 Kb to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 12 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (2), usage hint is GL_DYNAMIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 12 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (2), usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (7) with size:, 234.38 Kb to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 7 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 7 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (8) with size:, 234.38 Kb to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 8 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 8 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (9) with size:, 117.19 Kb to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 9 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 9 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (16) with size:, 432 bytes to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 16 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 16 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 16 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (17) with size:, 432 bytes to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 17 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 17 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 17 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Trying to allocate VBO (18) with size:, 216 bytes to location: VID

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 18 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) stored in VIDEO memory has been updated.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 18 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131185, SEVERITY_NOTIFICATION): Buffer detailed info: Buffer object 18 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131204, SEVERITY_LOW): Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131184, SEVERITY_LOW): Buffer info: 
Total VBO memory usage in the system:
 memType: SYSHEAP, 0 bytes Allocated, numAllocations: 0.
 memType: VID, 6.06 Mb Allocated, numAllocations: 15.
 memType: DMA_CACHED, 0 bytes Allocated, numAllocations: 0.
 memType: MALLOC, 276.30 Kb Allocated, numAllocations: 38.
 memType: PAGED_AND_MAPPED, 23.22 Mb Allocated, numAllocations: 30.
 memType: PAGED, 23.40 Mb Allocated, numAllocations: 32.

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131204, SEVERITY_LOW): Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131204, SEVERITY_LOW): Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131184, SEVERITY_LOW): Buffer info: 
Total VBO memory usage in the system:
 memType: SYSHEAP, 0 bytes Allocated, numAllocations: 0.
 memType: VID, 6.06 Mb Allocated, numAllocations: 15.
 memType: DMA_CACHED, 0 bytes Allocated, numAllocations: 0.
 memType: MALLOC, 276.30 Kb Allocated, numAllocations: 38.
 memType: PAGED_AND_MAPPED, 23.22 Mb Allocated, numAllocations: 30.
 memType: PAGED, 23.40 Mb Allocated, numAllocations: 32.

[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131204, SEVERITY_LOW): Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131204, SEVERITY_LOW): Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
[14:55:03] glDebug: (SOURCE_API, TYPE_OTHER, 131184, SEVERITY_LOW): Buffer info: 
Total VBO memory usage in the system:
 memType: SYSHEAP, 0 bytes Allocated, numAllocations: 0.
 memType: VID, 6.06 Mb Allocated, numAllocations: 15.
 memType: DMA_CACHED, 0 bytes Allocated, numAllocations: 0.
 memType: MALLOC, 276.30 Kb Allocated, numAllocations: 38.
 memType: PAGED_AND_MAPPED, 23.22 Mb Allocated, numAllocations: 30.
 memType: PAGED, 23.40 Mb Allocated, numAllocations: 32.
2

This is due to behaviours in the underlying graphics hardware which OpenGL, for the most part, tries to hide from you.

A “video memory VBO” is exactly what it says: a VBO that only exists in GPU memory. Otherwise it would exist in GPU memory and also be backed by a copy of it in system memory.

What’s happening is a system event on your computer is causing video memory to be evicted, so any resources which only exist in GPU memory are lost and must be recreated. Resources backed by a system memory copy can be trivially recreated - by the graphics driver - from that copy; resources only in GPU memory cannot and you must recreate them yourself. Again, this behaviour is typically something that OpenGL hides from you and you normally need to do absolutely nothing (people with experience of D3D9 or earlier would be painfully aware of it). The behaviour you’re seeing, and the solution you’ve identified, is 100% consistent with this diagnosis.

The system event that’s causing this is most likely a TDR: Timeout Detection and Recovery. Possible TDR causes include graphics applications that are hung, otherwise unresponsive, or that just take too long to do certain operations (I’d suggest that it also may happen if you’re overclocking, but that of course will not be formally documented by any hardware or software vendor). Again, you’ll see that this is all consistent. Driver bugs may also cause them, but any experienced programmer will tell you that in cases where somebody says “I have a driver bug”, 99% of the time it’s actually in their own code.

It’s not coincidental that you’ve seen this happening when performing other graphics tasks (viewing YouTube), and 3gb of video RAM usage seems excessive, particularly for a game that you seem to be saying is sprite-based and only uses basic/legacy OpenGL calls. A possible cause is that you might be allocating VBOs every frame, and therefore leaking GPU memory, but you would really need to talk a little about what your program is doing before we could make a better diagnosis.

3

[QUOTE=mhagain;1290745]Driver bugs may also cause them, but any experienced programmer will tell you that in cases where somebody says “I have a driver bug”, 99% of the time it’s actually in their own code.

A possible cause is that you might be allocating VBOs every frame, and therefore leaking GPU memory, but you would really need to talk a little about what your program is doing before we could make a better diagnosis.[/QUOTE]

mhagain, thank you for response!

I’ll try to list all particular qualities of my environment and my game. Maybe there will be some hints of the problem…

Environment:
[ul]
[li]I have a multi-monitor environment (2 displays). One time the bug was triggered by turning ON the second display (or at least it looked like that…)
[/li][li]Main display has 4K resolution (3840x2160), which, I suppose, is rather high.
[/li][li]Periodically, during watching YouTube videos I have driver crash (“Display driver stopped responding and has recovered”). But this is normal behavior these days, right?
[/li][/ul]
My game:
[ul]
[li]Uses one off-screen FBO with 4x MSAA
[/li][li]Uses only 2 types of draw calls - glDrawArrays() and glMultiDrawArrays()
[/li][li]I call glFinish() before glSwapBuffers()
[/li][li]I don’t recreate VBO’s every frame - I checked it with GLIntercept. Data transfered via glBufferSubData() calls.
[/li][li]VSync is ON
[/li][li]If VSync is OFF then it runs with relatively good FPS (>350), so, I would say, the game should not cause a TDR…
[/li][/ul]

Regarding memory leaks - No, it doesn’t look like that. GPU-Z not showing memory consumption growth. Also the occurrence of the bug is not related to the TIME LENGTH of the gameplay session - the bug, if occurs, occurs fast, during first 5 minutes after game start (not after playing for hours). And conversely - I had very long 5-hours gameplay sessions without that bug.
Regarding memory consumption - Usually, 50% of VRAM (1.5Gb of 3Gb) already consumed by other applications. And my game consumes 1.2Gb, which mostly consists of textures and FBO buffers.

Also, the NSight Timeline looks very strange (screenshot below).
As you can see, there is a very long glFinish() call, which lasted 5 seconds.
But all work on the GPU side looks finished (at least for me).
Corresponding data transfers and draw calls of the “long frame” finished in time similar to previous frames.
So why glFinish() hangs ??

4

It looks I found the solution. But I don’t understand why it works.

The bug has gone after I changed the order of calls and placed glFinish() after SwapBuffers().

I tested it 5 days and the bug not appeared, not even once. And vice versa - after I changed the order back to previous - the bug appeared after 15 min of gameplay.

When I think about it - having glFinish() in the very end of the Loop - seems rather logical to me. I can think of all other OpenGL calls, including SwapBuffers(), as “normal” commands which placed into the GPU’s Command Queue and glFinish() - is kinda special “meta-command” which forces the waiting of execution of all other commands in the GPU’s Command Queue.

So, yeah… Previous (incorrect) order - glFinish() before SwapBuffers() - was not very logical… But why it has so catastrophic consequences ?!?!

5

[QUOTE=subGlitch;1290744]I am experiencing very strange behavior which feels like a driver bug.

When my machine is loaded and (especially!) when I have opened YouTube stream this happens:

[ul]
[li]my game freezes for 1-5 seconds [/li][li]it restores but with one or two “corrupted” VBOs [/li][li]… [/li][/ul]
The only clue I have is that this have something related to lack of free VRAM - according to GPU-Z, almost all of GPU memory (3Gb) is used. …

Windows 8.1
NVidia card: GeForce GTX 780 Ti/PCIe/SSE2
NVidia driver: 391.01
OpenGL: 4.6, Compatibility profile[/QUOTE]

subGlitch, I work with NVidia GL drivers on Windows every day (I’ve been running the same 391.01 driver for a while in-fact). I’ve even diagnosed and fixed GPU memory overrun situations on the same GTX780 that you’ve got.

Just to clarify something that might be mis-inferred here. The typical behavior of the NVidia GL driver when it merely runs out of GPU memory is not to start “forgetting” the contents of objects and corrupting your program state. Instead, you just start getting very poor performance as the driver swaps objects out of and into GPU memory to satisfy your application’s rendering requests. So your app continues to render, and render correctly, but you get long pauses in the rendering while all of this “memory shuffling” is being done.

What you’re describing is something different, and I think mhagain’s guess that this may be TDR-instigated is a good one. If it is, you should be able to find record of this in the Windows event log (run Event Viewier). Getting a TDR is a big deal. It means the system sees the GPU as non-responsive and needs to reset it. When I’ve seen these before, it’s been associated with 1) misusing NVidia’s bindless extensions (where you can provide GPU addresses to the driver), 2) with a GPU shader that’s “gone rogue” and is consuming too much time, or 3) an NVidia driver bug. I’ve found over many years (15+) that NVidia driver bugs are pretty rare (their drivers are really solid), but they do pop up occasionally.

No. Definitely not! Certainly not on an NVidia GPU with NVidia drivers in a well-designed system that’s stable.

The bug has gone after I changed the order of calls and placed glFinish() after SwapBuffers().

As far as practice, that’s more typical. This blocks your draw thread until the frame rendering including swapbuffers downsample and blit/swap is complete (including VSync wait, if VSync is enabled and your app is directly driving the video output).

However, I’m not sure why this seems to fix it. Does this appear to avoid the problem with both VSync on and VSync off? If just with the former, could be you’re just not driving the GPU as hard and that reduction in heat and/or power is avoiding the TDRs (complete guess).

If I were you, I’d get your system stable. Double-check that you’re providing sufficient power to your GPU (you’ve got the additional power connectors plugged in, right?) and that your GPU isn’t overheating (though normally the GPU driver will slow down the GPU to reduce heat when needed). If you can, I’d try another GPU in the same system, and/or try your GPU in another system, and see if these problems go away. Also, make sure your system is up-to-date on updates for drivers and internal system software.

But why it has so catastrophic consequences ?!?!

And that is the million dollar question you have to answer. Just know that this is not normal and it is a big problem. Your system is not stable, and somehow you need to determine the root cause and fix it.

I doubt it’s your app, but if you can, feel-free to whittle it back the repro to a short stand-alone test program you can post. Others can then run it on their NVidia GPUs and drivers and confirm to you that it’s nothing that your app is doing that is causing this problem. I can even run it on a GTX780 for you, with the same NVidia GL drivers, on Windows (albeit 7 and not 8.1).

As far as GPU memory use/overrun monitoring, NVX_gpu_memory_info is very useful here. You can see how much of your GPU memory is free, and how much total memory has been “evicted” (paged off) the GPU. Evicted > 0 at any time tells you you’re overrunning GPU memory. If you don’t want to write code to use this, you can see the results of querying this extension with GPU Shark (just run Tools -> NVIDIA - GPU Memory Info). Note that GPU Shark is also built into GPU Caps Viewer (just click More GPU info…). GPU Caps Viewer by default displays more detailed GPU statistics information.

6

Dark Photon, thank you for such a comprehensive response!

Yes, additional power connectors plugged in.

No, it’s not overheating. GPU-Z shows stable average temperature (46-53 °C) and I never hear fans noise. Fans start to work hard if I turn VSync OFF, but I do this very rare and only for a few seconds - just to check how much FPS my game can go…

Yes! It turns out there are such records! For each bug occurance I have 1-2 warnings of event ID 4101 stating that the “Display driver nvlddmkm stopped responding and has successfully recovered”

And, probably, I have these warnings for each “driver crash” during watching YouTube videos also…

There are a lot of threads in the Internet regarding this “4101” issue, but one of them is very close to my situation:
https://answers.microsoft.com/en-us/windows/forum/windows_10-hardware-winpc/frequent-windows-event-4101display-driver-nvlddmkm/5e96ac5b-811b-4f1b-9251-388c470305aa?auth=1

They were not able to repro over 24 hours, so it’s something I didn’t give them or they didn’t test.
Only thing I know they didn’t test is they didn’t have the ability to test 2x monitors in 4k.

That is exactly my situation - I have 2 displays, one of them is 4K…

So, it looks like next few days I have to search answers in the Internet for this “4101” issue…