GLESZDoom - GZDoom for potatoes

[beloko]

I am adding a GLES 2 renderer to GZDoom 4 and thought it might be interesting to someone so will add some information here.

 

The main goal of this is performance, therefore ‘nice to have’ advanced rendering features have been removed or reduced. But it needs to work in 90% of the normal cases.

 

This is primarily for mobile platforms but it could be interesting to PC players because I think this could allow older GL 2.1 cards (with GLSL version 1.20) to work with GZDoom 4x. Maybe could be added to LZDoom..? At least it should make GL3 cards run better.

 

The GZDoom devs have done an incredible job splitting the rendering code and the hardware implementation therefore there is minimal change to the core files.

 

Removed features (In the GLES2 render code only)

All post-process code has been removed. GLES2 shaders can only have a single output so GBUFFER_PASS stuff can not work.

 

Materials have been removed (PBR, Specular). These could possible be added back later if less expensive implementation can be found

User shaders are disabled.

 

Shadow maps have been removed

 

Spot-light dynamic lights are removed, normal dynamic lights work BUT it’s currently limited to 32 lights per surface. This should be enough for 99% of cases I think.

Various lighting modes are removed – the most useful ones will be added back. Should look mostly normal by default.

 

Texture filtering modes are broken - this will be fixed ASAP.

 

Technical details:

Added multiple ‘pipelined’ buffers (Vertex, Light buffer, Viewpoint buffer) for GL and GLES, this allowed glFinish() to be removed, this give a substantial performance increase for mobile and older cards because the GPU can pipeline better.

 

There is no buffer memory mapping in core GLES2 therefore data buffers are backed by memory and need to be uploaded manually.

 

There are no Uniform Buffers or SSBO in GLES2, therefore all shader data which relies on this needs to be emulated with normal uniforms. This is especially apparent with dynamic light data.

 

Shader optimisation:

There are now almost no branching instructions in the gles2 shaders, instead all the switching branches are converted to precompilation ‘#defines’ and the shaders are compiled on-the-fly [Still a few to be removed]. This means lots of smaller shaders are compiled as they are used.  For every combination of these render-states a new shader is created:

 

                int textureMode;

                int texFlags;

                int blendFlags;

                bool twoDFog;

                bool fogEnabled;

                bool fogEquationRadial;

                bool colouredFog;

                bool doDesaturate;

                bool dynLightsMod;

                bool dynLightsSub;

                bool dynLightsAdd;

                bool useULightLevel;

 

In theory if EVERY combination of these were used then 1000’s of shaders should be created, in reality there are not many combinations made during a game.

This may seem slightly overkill but I found on older mobile hardware a single ‘if’ statement in the shader reduced performance by 2-3FPS! Removing the branching outweighed any penalties in switching more shaders in and out. This performance difference seems only apparent on older mobile and older desktop hardware, I think modern hardware intelligently patches shaders on-the-fly as the input uniforms change so branching isn’t as much of an issue?

 

Performance difference:

 

On modern mobile and desktop hardware these changes won’t much much difference or might even be worse!

 

On older mobile GPUs I can get 5x speed up.  I only have one old laptop GPU to test on (Radeon HD 4500) and I get about 3x speed increase (30fps to 90fps) compared to official release of GZDoom 4.5.

 

If you have an old GPU (Still needs OpenGL 3.3+ at the moment) and wanna try a test version a Windows build is here:

 

New releases will be here:

https://forum.zdoom.org/viewtopic.php?f=1&t=72361

 

Selecting OpenGL will use the GLES2 path, there will is visual difference and probably bugs (and may simply not work), but it would be interesting to see if it helps with performance.

 

Edited May 25, 2021 by beloko

[omx32x]

now gzdoom can run on my machine

[omx32x]

seens like i cant turn off linear filtering is this a glitch?

[beloko]

8 hours ago, omalefico32x said:

seens like i cant turn off linear filtering is this a glitch?

Yes sorry I forgot to say about that this is something I need to fix - it's currently fixed to linear.

GLES 2 is missing samplers but I will update to use the old method of setting filtering mode. 

[omx32x]

no problem keep up the good work

[beloko]

30 minutes ago, omalefico32x said:

no problem keep up the good work

Curious if you see much/any improvement in performance? I have loads of mobile devices to test with but only one old laptop to try it on. 

[omx32x]

19 minutes ago, beloko said:

Curious if you see much/any improvement in performance? I have loads of mobile devices to test with but only one old laptop to try it on. 

my laptop has limitation in the opengl so i cant run gzdoom but i can run it using the mesa 3d software gl render to boot it up and change its render to software mode so i can play

i dont have to do that with yours so its already a win

i also compared the general speed and gzdoom drops frames everytime theres a filter on my screen that is the yellow filter on item pickups and with the rad suit yours run fine with no issue what so ever

i also compared to lzdoom and while lzdoom still runs a bit faster overall i belive your version has more up to date code right?

its a cool project and i want to see how much it will improve in the future

[omx32x]

oh also i think it could be usefull if you have my specs

its an i5 2410 2.30 ghz with 8 gb of ram and no video card :(

yea its a cheap laptop with more ram

[vaa44]

Athlon x2 (2.8 ghz) gts 450. Map 31 btsx ep2 (with the mod EoA), The settings are the same as far as possible.

[beloko]

14 minutes ago, vaa44 said:

Athlon x2 (2.8 ghz) gts 450. Map 31 btsx ep2 (with the mod EoA), The settings are the same as far as possible.

 

Thanks for the test! Good to see they visually look the same.

[vaa44]

I also noticed that multisampling does not work.

[beloko]

6 minutes ago, vaa44 said:

I also noticed that multisampling does not work.

Yes I had to remove that as wasn't supported in GLES2. I believe you can make an EGL context with multisamping if it's supported by the hardware, but it doesn't check or do this currently.

[vaa44]

4 minutes ago, beloko said:

I believe you can make an EGL context with multisamping

If you mean forcing through the driver settings, then this does not work.

Another test. All the same, but without EoA. The difference is more noticeable.

[LexiMax]

Have you heard of bgfx?  I have long been intrigued by the project, as it seems to wrap many 3D API's going all the way back to GL2.1, D3D9, and WebGL 1.0, but have simply not had an excuse to take a closer look at it yet.  Just curious if such a project might be an asset to a hardware-renderer fork that aims to keep compatibility with potatoes.

Edited March 11, 2021 by AlexMax

[beloko]

41 minutes ago, AlexMax said:

Have you heard of bgfx?  I have long been intrigued by the project, as it seems to wrap many 3D API's going all the way back to GL2.1, D3D9, and WebGL 1.0, but have simply not had an excuse to take a closer look at it yet.  Just curious if such a project might be an asset to a hardware-renderer fork that aims to keep compatibility with potatoes.

That looks pretty awesome. It wouldn't help for my particular needs but I guess you should be able to use it in the engine with some work. The issue is I don't see how it can actually have full compatibility with all those platforms efficiently. You may end up having to the use the 'lowest common denominator' of features which could hurt the high end. Really what the GZDoom team have done with the engine is pretty awesome and is similar, Vulkan, OpenGL AND Software all from the same data, very nice.

 

[LexiMax]

On 3/11/2021 at 2:11 PM, beloko said:

The issue is I don't see how it can actually have full compatibility with all those platforms efficiently

 

I think the point is to have something that approaches a GL2.1/3 featureset that is written in the native API's of most platforms, in case GL support for a platform is non-existent or is mothballed/subpar compared to the native API from a speed or support perspective.  Since you already did the work of converting GZ to GLES2, I thought maybe your resulting renderer might be within the capabilities of that library.

 

However, as mentioned before, I haven't used the library and can't speak to it personally.  I just saw your cool project and it made my mind wander.  "Hrm...I wonder if..."

Edited March 12, 2021 by AlexMax

[MattFright]

I am extremely impressed with the performance of this, just WOW.

 

 

For context, i have tested it on Lunatic's MAP05 (which has about 500 enemies spawning and infighting for a solid 8 minutes, most enemies/corpses visible on the screen all at once and all so i figured it'd be a good test. GZDoom has never ran well for me with maps as complex as this (with some really weird exceptions), and LZDoom isn't different in the slightest in my experience, even under the most conservative settings. GLESZDoom on the other hand has managed to keep up an almost perfect 60FPS throughout the whole map without a problem.

 

I don't know how far off from a stable release this is, but count me as your #1 playtester, because this performance is so good i might even use this test version semi-regularly for occasions where GZDoom just doesn't want to cooperate.

 

If you're curious about what hardware i tested it on: Intel Core i3 5005U 2.00GHz, Intel HD Graphics 5500.

[Bauul]

For curiosity, I just tested this on the current WIP map for Elementalism, which is the kind of advanced GZDoom mapset I could see people with lower-end machines using this sourceport for.

 

On my laptop with an i5-7300HQ CPU @ 2.50GHz, and the laptop version of the GTX1060, my maximum FPS is way higher than GZDoom 4.5.0 - 300+ compared to 160 or so.  But the minimum FPS was actually lower, 30fps compared to about 45fps in GZDoom.

 

As you said, my rig isn't what this was designed for, but it's interesting to see how it plays out none the less.  

[beloko]

On 3/12/2021 at 3:38 PM, Bauul said:

For curiosity, I just tested this on the current WIP map for Elementalism, which is the kind of advanced GZDoom mapset I could see people with lower-end machines using this sourceport for.

 

On my laptop with an i5-7300HQ CPU @ 2.50GHz, and the laptop version of the GTX1060, my maximum FPS is way higher than GZDoom 4.5.0 - 300+ compared to 160 or so.  But the minimum FPS was actually lower, 30fps compared to about 45fps in GZDoom.

 

As you said, my rig isn't what this was designed for, but it's interesting to see how it plays out none the less.  

Yes interesting, thanks.

 

Edited March 13, 2021 by beloko

[omx32x]

i tried playing pirate doom the other day on it

it has way less rendering error running then then lzdoom (seriusly there are some levels on lzdoom that are almost unplayable there

it really is amazing though performace was an issue but i know im running it on the shitest pc possible so im not complaning

if you wanna someone to test this on very low hardware then cont me in

[Karl515]

Is this available for linux?

[Redneckerz]

Yes!

YES

YES!!

 

I've always wanted to see the PrBoom IOS renderer (GLES) based backported to PC, but any other GLES renderer will do just as fine!

 

Sadly can't run it yet due to the OGL3x requirement (Hey, i am one of those who use LZDoom for just that!) but if the GLES2 renderer for this GLESZDoom can be defaulted ill happily test this out as i run a Geforce 6150 set up and could benefit from this! If you do can get the GLES2 renderer natively without the OGL 3.x requirement, i'd love to push GLESZDoom.exe forward. :)

 

Being GLES based it looks extremely impressive from a performance point of view. This may also help well for other platforms, too.

 

@beloko please bring this up to Rachael at ZDF. If the code change is minimal, she may assist in getting seperate builds done in line with regular GZDoom.

 

I am not sure if @Graf Zahl could be swayed to push this in, but if ifs a minimal change, it could be a PR aswell.

 

Lastly, ill tag @drfrag for this because his array of low end ZDoom ports fits perfectly into this conversation.

 

@AlexMaxInteresting to see you mention BGFX again :) I actually suggested this i believe eons ago as an alternative, but it didn't generate much interest. Which is a shame, really.

 

[Wadmodder Shalton]

No more crappy potato PC framerates while playing Aeons of Death 6 or older versions of AEOD.

[xX_Lol6_Xx]

It would be awesome to see this in the zdoom downloads page, as an "alternative" just like LZDOOM

[Wadmodder Shalton]

Say goodbye to the aging MMX, 3dNow, & SSE for now, you served us well. Now we got AVX yet to come, this must go on.

[Redneckerz]

1 hour ago, Wadmodder Shalton said:

Say goodbye to the aging MMX, 3dNow, & SSE for now, you served us well. Now we got AVX yet to come, this must go on.

Don't come with this nonsense again. They are literally part of the processor.

 

Besides a modern CPU is dependent on MMX/3dNow and SSE as they are instruction sets in x86. Doom does not use them. Your screenshot highlights what the processor is saying to Doom: ''Hey! I am a processor, and i support these features.''

 

That's literally what it says. It does not say that Doom/GZDoom/GLESZDoom uses it, just that the processor has these features.

[beloko]

10 minutes ago, Redneckerz said:

Don't come with this nonsense again. They are literally part of the processor.

 

 

Ha I was trying to figure out what that meant. That thread is totally nonsensical, looks like expert tolling to me..

[beloko]

3 hours ago, Redneckerz said:

Yes!

YES

YES!!

 

I've always wanted to see the PrBoom IOS renderer (GLES) based backported to PC, but any other GLES renderer will do just as fine!

 

Sadly can't run it yet due to the OGL3x requirement (Hey, i am one of those who use LZDoom for just that!) but if the GLES2 renderer for this GLESZDoom can be defaulted ill happily test this out as i run a Geforce 6150 set up and could benefit from this! If you do can get the GLES2 renderer natively without the OGL 3.x requirement, i'd love to push GLESZDoom.exe forward. :)

 

Being GLES based it looks extremely impressive from a performance point of view. This may also help well for other platforms, too.

 

@beloko please bring this up to Rachael at ZDF. If the code change is minimal, she may assist in getting seperate builds done in line with regular GZDoom.
 

 

I am pretty sure it can be made to run on GL2.1 without too much trouble.  I don't have any GL2 hardware to test on though and have no idea how it will actually perform. Thank you for offering to help test this.

 

Wasn't really planning to do regular releases but can update with the latest Windows build I am currently running.

Thought it might be useful for G/LZdoom if they might be able to use some of it for a low end renderer. Code is a bit of mess though!

[CBM]

isnt zdoom and lzdoom meant for potato rigs that can't handle the advanced stuff in gzdoom like 3d models etc?

while gzdoom is meant to run doom on modern hardware with all the trimmings and as many upgrades as possible?

 

but I guess many of my old retro xp rigs could also run most gzdoom stuff if I really wanted 

Edited March 13, 2021 by CBM

[Redneckerz]

1 hour ago, beloko said:

I am pretty sure it can be made to run on GL2.1 without too much trouble.  I don't have any GL2 hardware to test on though and have no idea how it will actually perform. Thank you for offering to help test this.

Perhaps im a good use case since i run such bottom of the barrel hardware. Im just waiting it out :)

1 hour ago, beloko said:

 

Wasn't really planning to do regular releases but can update with the latest Windows build I am currently running.

I'd totally love to. ^^ In my mind/experience, a GLES renderer usually performs a lot faster on PC than a desktop GL2 renderer. This is ofcourse entirely subjective as programming skill plays a part, but its partially why i got so excited when you mentioned you made a GLES 2 renderer.

1 hour ago, beloko said:

Thought it might be useful for G/LZdoom if they might be able to use some of it for a low end renderer. Code is a bit of mess though!

I think this could be a good fallback layer since OpenGLES is an embedded long-term standard. But you really should put this through the works with Rachael - She has a Raspberry Pi with a seperate GZDoom build running who surely may be interested in a crossplatform GLES2 renderer that runs on PC and mobile hardware.