GZDoom benchmark info needed

[Graf Zahl]

With multisampling:
GL_RGBA16 is 14 fps, 41 ms for finishing
GL_RGBA8 is 19 fps, 24 ms for finishing
no renderbuffer is 34 fps, 4ms for finshing.

Without multisampling there is no overhead with GL_RGBA8, I haven't tested this with GL_RGBA16 yet.

For me 2.1.1 is doing multisampling.

[dpJudas]

Maybe that glGetFramebufferParameteriv function isn't working reliably for the default frame buffer. It is a bit tricky for me to tell by visual inspection as the combination of old eyes and 192 dpi makes it impossible to tell.

I guess the good news is it is "only" a multisampling issue. I can imagine the RGBA8 vs RGBA16 could make a difference on low end cards with poor fill rate. Adding a setting for it should be trivial enough in any case.

[dpJudas]

I found an interesting article about buffer clears and invalidation: https://community.arm.com/groups/arm-ma ... amebuffers. Written for OpenGL ES, but I think same things hold true for desktop OpenGL.

It mentions 3 things important for performance:

• Binding each FBO (other than FBO 0) exactly once in each frame, rendering it to completion in a contiguous sequence of API calls.
• Calling glClear() at the start of each FBO’s rendering sequence, for all attachments where the old value is not needed.
• Calling glInvalidateFramebuffer() or glDiscardFramebufferExt() at the end of each FBO’s rendering sequence, before switching to a different FBO, for all attachments which are simply transient working buffers for the intermediate state.

I'm going to spend a little making sure that all three are true in gzdoom. With some luck that will restore the multisampling performance. Also going to hook up the debug API they added in 4.3 to see if the driver is giving any warnings or anything.