gDEBugger report + issue

[dany-on-demand]

I tried to run over some performance analysis over the stutter I'm getting.

During the stutter, FPS/s really drops to 0.5. OGL calls don't change, CPU sometimes went tiny bit higher(5-10%) but usually stayed the same.

GL calls average 2-4k. And doesn't change when a grenade explodes. A huge improvment over iceball's 2-4-8k and 27k when not looking at the grenade explosion, and 32k when looking at it.

One small issue, some of the debug buttons behave weirdly. I discovered that turning on wireframe mode on the back buffer made you not see anything, and gDEBugger probably turns it on for both. I had to hardcode it in, and I got what I wanted. Also eliminating shaders for me turns the screen yellow and once you "turn the shaders back on" it stays yellow.

Also I observed there is no depth+stencil buffer used/allocated. I wonder why it is in iceball, where it just wastes VRAM.

[iamgreaser]

"depth buffer wastes VRAM"

Uhhh... you have no idea how important the depth buffer is, do you? For a 1366x768 screen it tends to use up a bit over 4MB which really isn't that much for... well, an Intel Atom won't suffer.

[dany-on-demand]

Sorry, I wasn't talking about the depth buffer, but the stencil buffer. I learned that depth and stencil buffers are often packed into the same space, that's why I said depth+stencil buffer.

[yvt]

• OS uses a depth buffer.
• OS doesn't have a depth buffer in default framebuffer. Instead, it allocates one in the form of texture.
• Depth buffer is required for fast hidden surface removal.
• gDEBugger's wireframe mode doesn't work as expected for OS because OS's post-processing phase transfers a screen image using two screen-sized polygons.
• OS has its own timing measure mechanism that can be enabled with r_debugTiming. When enabled, this outputs how much time has been taken to process each rendering stage to SystemMessages.log. This should be useful for performance analysis.

[dany-on-demand]

Thanks for the explanation yvt, I'll use that!