The new OpenGL ES Renderer... WOW!

[bLUEbYTE]

I've been out of the loop for a while and have just gotten back to GZDoom. A bit late to the party obviously, since this renderer seems to have been added in v4.7.

Fired up GZDoom 4.10.0, and conducted my usual benchmark: MAP18 - Courtyard. I knew the Vulkan renderer always had micro-stutters in the past, and also slightly slower than OpenGL on my PC, so I had OpenGL selected as the backend. Light shadow maps, postprocessing were disabled, dynamic lights & bright maps enabled, with most rendering settings left at defaults. 1080p resolution.

I went to the center of the map as usual, with heaps of monsters spawning. The FPS was around 20-25 FPS.
I then switched to the OpenGL ES renderer, restarted the game, did the same test. Guess what... 120 FPS solid throughout!

For another informal 'benchmark', I loaded up the Technicolor Antichrist Box map, which is loaded with fancy stuff and gives a hard time to my GPU. In OpenGL, it was around 15-20 FPS. With OpenGL ES renderer, the FPS is doubled.

This is soooo good. A huge thank you to emile_b, Rachael, and everyone else who made this a reality. I regret not having taken part in the initial testing & benchmarks, but I still wanted to let you know how much of a difference it made on a relatively new system.

Specs: 8th gen Intel NUC with 8259u CPU, Iris plus 655 iGPU running on WIndows 11.

[Professor Hastig]

This is a bit surprising for a GPU like that - it should be more than adequate to run both the full GL renderer and Vulkan without performance loss. In particular it should run best with Vulkan.

[dpJudas]

On my Dell XP 15 9500 (2 years old laptop), at 1920x1080, MAP18 - near the middle of the courtyard:

Intel UHD Graphics 770 iGPU:

Vulkan: 45 FPS
OpenGL: 45 FPS
OpenGL ES: 122 FPS

Nvidia Geforce 1650 Ti (laptop GPU):

Vulkan: 117 FPS
OpenGL: 117 FPS
OpenGL ES: 207 FPS

So both for NV and Intel I can confirm the numbers bluebyte is seeing. My personal guess would be the heavier shader, but there are also other possibilities (the post process present shader or the rgba16 frame buffer).

[Graf Zahl]

This definitely needs to be investigated. The difference is a bit extreme. All 3 GPUs being listed here should be able to run the game at decent frame rates. ESPECIALLY MAP18.

BTW, I get 140 fps with full GL and Vulkan and 840 fps with GLES on a Core i7-12700 with a Geforce 1060.
Some recent change must have done something really, really bad to the default renderer.

[dpJudas]

On my laptop I was testing with a (relatively) old version 4.8.2 - so it happened before that.

I did some slight further tests, like using the same post process present shader and rgba8 framebuffer format as OpenGL ES. Neither of those made any difference. I even went as far as oversimplifying main.fp so that it was actually even more simple than the OpenGL ES version and OpenGL ES still won by a significant margin.

Another interesting thing I noticed was that the FPS was fluctuating wildly when using Vulkan, while stable with OpenGL ES. It is a bit of a mystery exactly what is going on here.

[Graf Zahl]

I did a few more checks. What's slowing MAP18 down so much is the dynamic lights from all those bonus items lying around.

In 3.3.2 it's still fine, in 3.4.0 it is slow. I do not have any intermediate versions available right now but I think this was when the offscreen framebuffer was introduced.
This is some really weird shit.

[dpJudas]

Been testing some more and it seems to be related to the "pipelining" part. It is the Finish that is slow:

OpenGL ES:

All=1.495, Render=0.828, Setup=0.177, Portal=0.000, Drawcalls=0.291, Postprocess=0.071, Finish=0.349

Vulkan:

All=4.955, Render=0.270, Setup=0.334, Portal=0.000, Drawcalls=0.150, Postprocess=0.118, Finish=4.134

I can actually get fairly close to the OpenGL ES performance by significantly lowering vk_submit_size. If I lower it to 60 draw calls for each time the backend submits a command buffer then I'm almost up to same speed.

Perhaps it has to do with when you have both a very slow CPU and a slow GPU then them not always working in parallel is hitting so much harder? We both have very high CPU's which could mask that.

Btw the OpenGL ES backend also uses the post process frame buffer and present, so it shouldn't be that.

[dpJudas]

Forgot to mention - my last comment is from just testing with MAP01. Just a sec, will see what MAP18 has to say to a low vk_submit_size

[Graf Zahl]

It's really weird stuff. I simlified the lightContribution function for testing and got a massive fps increasse by that. It looks like some of those rewrites for better lighting features really hit a bad spot on the GPU which on GLES gets defined out.

[dpJudas]

Ah that might be it then. The OpenGL ES backend uses defines for a lot of that.

The vk_submit_size thing has no effect on MAP18 though, but it does still tell me that on lowend hardware the "glFinish" call has a bigger impact than I expected.

[Graf Zahl]

So I guess for the dynamic light stuff a bit of code optimizaton is needed then. Not down to using #defines but maybe optimized variants for cases where not all features are needed.

[dpJudas]

If I comment out the shadowContribution part and set vk_submit_size to 250, then I get the same speed with the vulkan backend as I do with OpenGL ES on this laptop.

[Graf Zahl]

Oh, so it's the shadowmap. Yeah, that's definitely too slow for those Intel iGPUs. My old Geforce 550TI had similar performance and shadowmaps were a crapshoot on it. It's still a bit weird that MAP18 is so badly affected. Most of these bonus items should be flagged to not need any shadowmap tests at all.

[dpJudas]

I don't have the shadowmaps enabled. Either the early out shadowAttenuation doesn't work or it was the final straw that changed the performance (out of registers, etc.).

Btw I don't think it is the sprites themselves, but the flat surface below them.

[Graf Zahl]

Sure it is - one large sector with lots and lots of lights.