Testing a new rendering backend (New tests needed)

[Redneckerz]

The Adreno 200 was the first unified shader design from Qualcomm. It's feature set is more current-thinking than GF's 6x arch.
Ill get back with results.

Yes. So here's the problem we're facing with this branch - it is ultimately geared towards far more modern hardware than anything that still requires OpenGL 2.x on desktop systems - which according to Steam's hardware survey are Geforce Series 6 and 7 and Intel GMA. For Geforce Series 6 I wouldn't expect any shader based approach to work and for the other two we got no samples yet.

Typically mobile GPU's are at the very base supporting GLES 2.0 - based on OGL 2.x. So that's the baseline (Which is what a Mali 400/450 supports and that still gets used anywhere). Fortunately even Mali GPU's tend to scale up in feature set and get OGL 3x and even Vulkan 1.0 contexts.

The main question is - what do users in Brazil really have? Do they really use GL 2 hardware or are they already on GL 3 hardware that in more developed countries has also become obsolete some 5-8 years ago? Since we have no good metrics for GZDoom, let's just have a look what we do have:

The problem is price. PlayStation 2 is basically the go-to machine there, because anything more modern is godly uncostly over there. Russians also like to muck around with software way beyond what makes sense. They still make new J2ME games, some even with Quake/Doom assets.

This kind of moonshine homebrew developing has its charms though.

[Redneckerz]

Alright, results are in, and also have a bug to report:

• The GZDoom bench is incomplete, as test 4 (Hurt) cannot be completed and throws up an error. I have attached a screenshot of the error message in the zip (Utilizing latest link in the first post)

Code: Select all

CPU: AMD Athlon X2 215 @ stock
GPU: GeForce 6150 IGP
RAM: 3 GB DDR2

[Rachael]

Ooof. That one hits home pretty hard.

That is a very disappointing result from the branch, especially on that hardware. So it's clearly hit or miss depending on the hardware, but mostly it's either on par (if we're lucky) or worse, and in some rare instances better.

[Graf Zahl]

This comes as no surprise to me. I once had a Geforce 6800 and even using the simplest shaders made the performance break down. We see the same here.
On these old cards it is virtually impossible to run anything using shaders for the complete scene - you may run some occasional shaders for special effects, but then have to be careful that the effect does not cover too much of the screen.

Realistically, the *ONLY* viable hardware for it may be Intel GMA, but seeing that result here it may just be a waste of time pursuing this approach for low end support.

[drfrag]

Now it doesn't crash but it's nvidia hardware.

[Redneckerz]

Ooof. That one hits home pretty hard.

That is a very disappointing result from the branch, especially on that hardware. So it's clearly hit or miss depending on the hardware, but mostly it's either on par (if we're lucky) or worse, and in some rare instances better.

I may re-run the test later to be sure because in not feeling okay at the test yet. Beloko did throw up a new build yesterday with fixes.

Ill bring him up to speed on the result.

It ought to use hardware rendering, but the LZ build gets the most performance in.

[Graf Zahl]

Read my last post. This performance characteristic is absolutely to be expected for Geforce 6 series. It simply runs a lot better without shaders.

[Redneckerz]

Read my last post. This performance characteristic is absolutely to be expected for Geforce 6 series. It simply runs a lot better without shaders.

I onderstand. I just want to be certain i didn't miss anything.

[Rachael]

Well for what it's worth the same author was working on his master branch which does not seem to be quite as far behind, but it is nevertheless divergent from the branch I tried here (which was the gles_remove_post he originally posted).

Looking at the Doomworld thread he did link to his master branch. I guess I'll have a go at it and see what happens.

[Graf Zahl]

The main difference is that it now tries to actually map the buffer instead of doing full uploads. It may be a bit faster but I don't expect any miracles from that. Most of the changes are for making it work on lower end mobile hardware.

You can merge GZDoom's master with his old branch to make comparisons easier.

[emile_b]

Hi. Seems I do have an account for this forum.

Thanks Rachael for taking a look at this, I hope it doesn't waste too much time for people if it turns out to be useless!

I originally did this change just as a test to see if I could improve performance on some older mobile GPUs. I found on older GLES3 mobile GPUs there was a cliff edge in performance when running GZDoom 4, this seemed to be mostly down to the fragment shader. It's seems on these low end mobile GPUs the fragment shader needs to be basically max 5 lines of code with no branching otherwise it craps out ha.

For me what is interesting is the difference between GZDoom 4 + OpenGL 3 and GZDoom 4 + GLES because I heard the legacy 3.8xx branch of LZDoom might be discontinued. This branch is just to try and keep mobile users with old devices happy for a while longer until they EVENTUALLY upgrade.

Anyway I just posted this on Doomworld because I thought it might be interesting, I really don't know how it would translate to PC performance but it seemed to help on a couple of my older laptops. The performance improvement seemed most apparent in 'normal' sized maps (Eg vanilla maps with mods like Project Brutality), but large maps seemed to suffer.

I'm using this branch to test renderer changes (just because its much faster then developing on Android) on Windows PC:
https://github.com/emileb/gzdoom/tree/master

When running on Windows this it uses all the existing GL context creation (so will needs OpenGL GL 3), but it only uses the GLES2 subset of features.

I have never actually tested on PC GL2 hardware because I don't have any. But as Graf says above it may be non starter simply due to the use of user shaders (i.e not fixed function), possibly that hardware is just too old now.

Happy to help out if I can, I know the code is a bit of mess sorry!

[Graf Zahl]

I have never actually tested on PC GL2 hardware because I don't have any. But as Graf says above it may be non starter simply due to the use of user shaders (i.e not fixed function), possibly that hardware is just too old now.

So far we only have tested one single series of GL 2 hardware - and one where I have known for 17 years that shaders cannot be used on it in any realistic scenario.
We'd have to see how it fares on Geforce 7 series cards, ATI Radeon X and Intel GMA as well to see how things really look. But the virtual non-reaction to this discussion surely shows that the number of such users among this forum's active members is tiny. I really wonder how many are left - but to find that out we'd have to run a survey with LZDoom...

[Rachael]

Happy to help out if I can, I know the code is a bit of mess sorry!

I am not here to critique your code, I am sure I have done far worse and I could not have pulled this off myself, I have absolutely zero OpenGL programming experience, none of which was even in GLES either. Doing that kind of thing just hasn't appealed to me.

The only complaint that I have is that it's not completely isolated. I would have loved to just add it as a completely separate backend to GZDoom, even accepting that I would have had to write some function virtuals in order to be able to decode the new backend's abilities so that GZDoom would continue to function fully featured on OpenGL and Vulkan.

The pipelining thing is interesting though - modern systems don't seem to have any use for it, but with it being tied to the backend there's no way to test it all by itself just to be sure. But that is a candidate thing that might benefit all the backends and improve performance of GZDoom overall even on modern systems, just not sure unless we get a chance to isolate it though.

[emile_b]

Happy to help out if I can, I know the code is a bit of mess sorry!

I am not here to critique your code, I am sure I have done far worse and I could not have pulled this off myself, I have absolutely zero OpenGL programming experience, none of which was even in GLES either. Doing that kind of thing just hasn't appealed to me.

The only complaint that I have is that it's not completely isolated. I would have loved to just add it as a completely separate backend to GZDoom, even accepting that I would have had to write some function virtuals in order to be able to decode the new backend's abilities so that GZDoom would continue to function fully featured on OpenGL and Vulkan.

The pipelining thing is interesting though - modern systems don't seem to have any use for it, but with it being tied to the backend there's no way to test it all by itself just to be sure. But that is a candidate thing that might benefit all the backends and improve performance of GZDoom overall even on modern systems, just not sure unless we get a chance to isolate it though.

Yes completely agree it needs some better separation. I have tried to do it so OpenGL and Vulkan still work in fact (seem to for me), BUT all renderers now use the pipeline thing. I *think* if you set gl_pipeline_depth to 1 it basically behaves the same as before.

Indeed the pipeline code is the most invasive in to the rest of the code, I actually wanted it there also for the normal OpenGL renderer as well because it makes a HUGE difference on all mobile GPUs including modern ones.

Don't know if it helps but I put the pipeline stuff in first, the 3 commits up to here:
https://github.com/emileb/gzdoom/commit ... 6a9631cd78
Compiling that should make a build which in which the only change is the buffer pipeline for OpenGL. Unfortunately I don't know any Vulkan so don't have any idea if it would make any difference there.

Anyway I'm going to see what I can push back some code up into the gles source files, I too want as little change in the rest of the engine as possible as it makes it easier to merge new stuff.

Cheers! Emile.

[Phredreeke]

The problem is price. PlayStation 2 is basically the go-to machine there, because anything more modern is godly uncostly over there. Russians also like to muck around with software way beyond what makes sense. They still make new J2ME games, some even with Quake/Doom assets.

This kind of moonshine homebrew developing has its charms though.

I'm not sure of what benefit there would be to bring GZDoom to such old hardware? I'd expect it to choke on anything but the simplest mods, and if you wanna play Vanilla WADs there are already countless ports that do that.