Testing a new rendering backend (New tests needed)

[SanyaWaffles]

I think people forget that GZDoom is a modern source port. It's meant to be modern - support modern hardware, support modern modding techniques, and lately has been powering several indie projects meant for non-vanilla experiences - something more vanilla Doom could theoretically do with DEH patches, but people sometimes want more. GZDoom offers that and more.

I get there's a niche retro scene, and I wholly respect it. However, one thing you gotta accept about these things is there's going to be some things it can't do with modern engines - and to demand this modern source port support ancient hardware is kind of defeating the purpose.

Doesn't mean you can't roll your own vanilla engine fork to make a whole new game. Doesn't mean you can't tinker. Hell, go wild, I'd like to see what people can do with such things.

Frankly all this nagging to get Graf to support Intel i486DX with a built in FPU[1] seems to be... well... annoying.

I get not having access to the latest and greatest tech. I'm on disability, and my current rig's going to have to do for quite some time as it's likely going to be unfeasible to upgrade with my limited budget and the shortages of hardware due to sclaping. However I'm not owed anything to GZDoom's developers, even though it's my engine of choice.

I understand Graf's rationale for not wanting to support such ancient hardware, especially since it's becoming harder to find such hardware to test it on first-hand, especially since the retro scene has driven up the prices on eBay.

That said, if this branch can offer a stopgap for older graphics cards given more and more they are becoming scarce, I'm all for it - but people might have to accept new features require more modern hardware, and at some point there's a compromise that needs to be made - either you want retro compatibility with less features, or more features locked into newer 2010+ hardware.

[1]I'm being hyperbolic here for the sake of making a point.

[Rachael]

Out of curiosity, while waiting for my GPU that's been in shipping limbo all week (bleh!) ... I had a spare ATI Radeon HD 4850 laying around and I decided yesterday to finish assembling my new machine with it. Other than that GPU, the rig is all quite modern tech, nothing older than 2 years.

I ran GZDoom on that ATI and was quite pleasantly surprised - no glitches, it ran pretty well. Exceeded 60 FPS in all backends, at least on the vanilla maps. I might out of curiosity try Frozen Time on it - I am not expecting miracles, but it might run better than it previously did with my older machines that it came from.

To be quite fair though - the processor in that thing was a hexacore Ryzen 5 CPU, so I guess I should have expected it to perform better since the CPU was the main deadlock with my previous experiences with ATI cards. Once a scene goes heavy shaders it does start to struggle a bit.

(On that note, if I had known that it would've performed so well on an older ATI card, I probably would have ordered a newer ATI instead of an NVidia)

Anyway ... that just goes to show you how old of a card GZDoom still runs on.

[Graf Zahl]

it's becoming harder to find such hardware to test it on first-hand, especially since the retro scene has driven up the prices on eBay.

I noticed that a Geforce 8800 sells for more than a Geforce 550ti. There's some weird people out there...
All that said, if people want to build retro rigs, that's all fine and well - but please don't demand that currently developed software make some efforts to support these things. They are a blast from the past and should be treated as such, i.e. their main purpose should be to run old software in their native environment. But still, the effort some open source software invests in this segment is ridiculous. Some are willingly crippling their software or refuse to modernize out of fear of losing this user segment. That these actions may lose them 10x as many users on the other end of the spectrum is conveniently ignored.

Personally I think that current LZDoom is good enough to service this low end segment, even if it doesn't support all features.

[Rachael]

They are a blast from the past and should be treated as such, i.e. their main purpose should be to run old software in their native environment.

Well the good news is - if you still have your old GeForce 2 from way back more than 20 years ago, GZDoom 1.8.6 still runs on it!

(And yes, there was a point to that - old versions of GZDoom are still available from the eras when such hardware was available and in use)

[Graf Zahl]

I wonder how well my pre-2004 system, which had a Geforce 2, would run any of those larger maps...

[Rachael]

At any rate - I do still plan to work with Beloko's branch if/when it is finished - but I don't expect that I will be investing too much time with it. Seeing as how it was hard to find people who still even have genuine GL 2.x hardware, if it breaks I'll probably spend a day or so at most to fix it before I give up on it.

But otherwise, as long as it updates smoothly with the rest of GZDoom, having that branch available as a stopgap (or even as an alternative to LZDoom) I am sure will be helpful.

LZDoom is surely better on such hardware since its renderer was written during a time when GL 2.x hardware actually was in use - whereas this branch clearly was not, and it is being adapted to run on less powerful hardware from what it is now. I remember one of the first diversions that GZDoom took before LZDoom was created was new code for how the floors were drawn (if I remember right) which worked way better for more modern hardware since it involved less CPU bottlenecking. And if I am to guess there have been more changes like that since then, offloading more work to the GPU and freeing the CPU to handle things that were more important and not rendering related.

[Graf Zahl]

The biggest change is that LZDoom still has the fixed function render path - which on Geforce Series 6 makes a huge difference.
This got removed when it became clear that the change to sector rendering was not working well with GL2.

Of course, fixed function does not exist on GLES2, so for Beloko's purposes it has no value.

[Redneckerz]

Out of curiosity, while waiting for my GPU that's been in shipping limbo all week (bleh!) ... I had a spare ATI Radeon HD 4850 laying around and I decided yesterday to finish assembling my new machine with it. Other than that GPU, the rig is all quite modern tech, nothing older than 2 years.

I ran GZDoom on that ATI and was quite pleasantly surprised - no glitches, it ran pretty well. Exceeded 60 FPS in all backends, at least on the vanilla maps. I might out of curiosity try Frozen Time on it - I am not expecting miracles, but it might run better than it previously did with my older machines that it came from.

To be quite fair though - the processor in that thing was a hexacore Ryzen 5 CPU, so I guess I should have expected it to perform better since the CPU was the main deadlock with my previous experiences with ATI cards. Once a scene goes heavy shaders it does start to struggle a bit.

(On that note, if I had known that it would've performed so well on an older ATI card, I probably would have ordered a newer ATI instead of an NVidia)

Anyway ... that just goes to show you how old of a card GZDoom still runs on.

Back in the day a HD 4850 was dirt cheap for a top end card (Talking 150/200 euros here). Compare that to today. 200 euros gets you absolutely nothing. Ofcourse, different times, different era's.

Really wish the GLES backend did do well, but i reckon GF6xx is just not taking that. GLES2, whilst being OGL 2.x compliant in many sectors, works better around Intel hardware with some eye on the future - A GF6xx is not. Despite being able to run shaders, it runs better with fixed function hardware (Which is several generations older, like the aforementioned GF2.)

Nevertheless, i would be happy with any build that offers GLES 2.x rendering - If not for Mobile ARM based hardware, than for low end current hardware or somewhat older stuff. How would a Athlon 200G with Vega 3 stack against current GZDoom, LZDoom and this GZDoom-GLES? Its modern enough to run the whole feature set, but it is low end enough to be beneficial with GLES 2. Performance of Vega 3 is in the GF8x range.

Or maybe we need to look at older AMD APU's, GCN based but with Jaguar cores.

So far i can tell, GZDoom-GLES with its seperate render back end would join an army of low end ports:
- GZDoom 1.8.6 (Heck, Zandronum is still made on this)
- LZDoom
- ZDoom32 (It has a GL2.x renderer)
- ZDoom LE
- ZDoom CL
- and now GZDoom-GLES

Though drfrag is behind most of these.

[Graf Zahl]

Nevertheless, i would be happy with any build that offers GLES 2.x rendering - If not for Mobile ARM based hardware, than for low end current hardware or somewhat older stuff. How would a Athlon 200G with Vega 3 stack against current GZDoom, LZDoom and this GZDoom-GLES? Its modern enough to run the whole feature set, but it is low end enough to be beneficial with GLES 2. Performance of Vega 3 is in the GF8x range.

Ultimately it depends on how costly shader branching is. If it is relatively cheap, current GZDoom will work better, if not it depends on whether shader switching is more costly than shader branching.
Keep in mind that GLESZDoom does amputate the feature set to simplify things. Just turning off software lighting in GZDoom can do a lot with modern GZDoom on these cards.

Or maybe we need to look at older AMD APU's, GCN based but with Jaguar cores.

So far i can tell, GZDoom-GLES with its seperate render back end would join an army of low end ports:
- GZDoom 1.8.6 (Heck, Zandronum is still made on this)
- LZDoom
- ZDoom32 (It has a GL2.x renderer)
- ZDoom LE
- ZDoom CL
- and now GZDoom-GLES

Though drfrag is behind most of these.

GZDoom 1.8.6 will probably run best. All of drfrag's iterations won't matter much - the renderer at the bottom is still mostly the same, i.e. GZDoom 3.3.

[Rachael]

So, about the HD 4850:

I didn't do the full tests, because LZDoom with -glversion 2 is glitched on that system. So I did only Frozen Time with this, and got an interesting result.

---

LZDoom with -glversion 3:

Code: Select all • Expand view

Map map01: "Hydroelectric Plant",
x = 4670.0000, y = 5980.0000, z = 476.0000, angle = 89.9011, pitch = 0.8350
Walls: 14570 (0 splits, 2007 t-splits, 36216 vertices)
Flats: 848 (26533 primitives, 118148 vertices)
Sprites: 796, Decals=0, Portals: 1
W: Render=16.645, Setup=2.994, Clip=3.832
F: Render=20.338, Setup=0.073
S: Render=2.376, Setup=0.893
All=52.926, Render=39.965, Setup=11.789, BSP = 3.981, Portal=0.079, Drawcalls=33.461, Postprocess=0.127, Finish=0.947
DLight - Walls: 0 processed, 0 rendered - Flats: 0 processed, 0 rendered
Missing textures: 0 upper, 0 lower, 0.000 ms
18 fps


GLESZDoom:

Code: Select all • Expand view

Map map01: "Hydroelectric Plant",
x = 4670.0000, y = 5980.0000, z = 476.0000, angle = 89.8956, pitch = 0.5219
19 fps

Walls: 14595 (0 splits, 2007 t-splits, 36300 vertices)
Flats: 989 (989 primitives, 226446 vertices)
Sprites: 832, Decals=0, Portals: 1, Command buffers: 0
BSP = 3.700, Clip=5.366
W: Render=33.303, Setup=3.915
F: Render=3.808, Setup=0.198
S: Render=3.752, Setup=0.490
2D: 0.201 Finish3D: 0.049
Main thread total=9.070, Main thread waiting=0.004 Worker thread total=9.054, Worker thread waiting=4.452
All=51.128, Render=41.054, Setup=9.201, Portal=0.350, Drawcalls=21.974, Postprocess=0.056, Finish=0.129
DLight - Walls: 0 processed, 0 rendered - Flats: 0 processed, 0 rendered


Modern unmodified GZDoom:

Code: Select all • Expand view

Map map01: "Hydroelectric Plant",
x = 4670.0000, y = 5980.0000, z = 476.0000, angle = 89.8956, pitch = 0.5219
8 fps

Walls: 14595 (0 splits, 2007 t-splits, 36300 vertices)
Flats: 989 (989 primitives, 226446 vertices)
Sprites: 832, Decals=0, Portals: 1, Command buffers: 0
BSP = 4.563, Clip=6.452
W: Render=81.257, Setup=6.145
F: Render=2.689, Setup=0.293
S: Render=24.795, Setup=0.524
2D: 0.313 Finish3D: 22.135
Main thread total=11.021, Main thread waiting=0.007 Worker thread total=11.003, Worker thread waiting=4.041
All=121.404, Render=108.935, Setup=11.056, Portal=0.131, Drawcalls=96.718, Postprocess=0.146, Finish=0.634
DLight - Walls: 0 processed, 0 rendered - Flats: 0 processed, 0 rendered


For what it's worth here's the system specs:

---

- ATI Radeon HD4850 (driver version 8.970.100.9001 dated 2015-01-13, obtained via Windows Update)
- 32 gb ram
- Ryzen 5 1600 @ 3.2 ghz

If interested I can run the full tests on that system, but seeing as how the main baseline that we were comparing against doesn't work properly, I was not sure if it would be worth it.

[Graf Zahl]

Have you made sure to use the same settings? This looks to me like current GZDoom is running into some features that may be too heavy for this old hardware. The other two are very clearly limited by processing power of the GPU, so running GZDoom with anything more may kill it.

[Rachael]

They were all started exactly the same way - wiping the ini and using the settings as indicated in the batch file. Only difference is I started LZDoom with -version 3 instead of what I last distributed. So the settings are almost all default other than what the batch file changes.

When I tested modern GZDoom, I simply swapped out to the version I had compiled this morning and put it in the same spot as the kit version.

My hypothesis is that the shader processor is the limiting factor. When I run other GL programs, if I use forward rendering instead of deferred rendering, I get FPS speeds magnitudes higher than equivalent scenes on my GTX 860M (which is astonishing since the 860M is 5 years newer). However, once I activate deferred rendering, the FPS plummets to 1/10th what it was in the exact same scene, where the 860M would run at about equivalent speed to what it did for forward rendering with the same settings in the same scene as was tested with the old Radeon.

[Phredreeke]

Nevertheless, i would be happy with any build that offers GLES 2.x rendering - If not for Mobile ARM based hardware, than for low end current hardware or somewhat older stuff. How would a Athlon 200G with Vega 3 stack against current GZDoom, LZDoom and this GZDoom-GLES? Its modern enough to run the whole feature set, but it is low end enough to be beneficial with GLES 2. Performance of Vega 3 is in the GF8x range.

What? That's a 2018 APU. In fact I think all GCN-based AMD GPUs and APUs support Vulkan...

[Graf Zahl]

Vulkan or not, it's surely good enough for modern GZDoom, even if it cannot handle all features.

[Redneckerz]

GZDoom 1.8.6 will probably run best. All of drfrag's iterations won't matter much - the renderer at the bottom is still mostly the same, i.e. GZDoom 3.3.

Would it? Because drfrag's iterations use significantly older GZDoom bases. ZDoom32 uses GZDoom 1.9.1 as its basis, for instance.

The last GZDoom version to support OGL 1.3 was 1.8.4. The last one for OGL 1.4 was 1.8.6. OGL 1.1 is still supported on 1.0.18, as frag proved it ran there. The first one for OGL 2.0 was 1.9.1 and the last one to support OpenGL2 is either 3.4.0 from an old post from yours, or 3.4.1 if i have to go with frag's words. 3.7 Vintage also had this, apparently.

So yeah, i do think that for a Geforce 6x based GPU, 1.8.6 will do well since its an OGL 1.4 renderer.

What? That's a 2018 APU. In fact I think all GCN-based AMD GPUs and APUs support Vulkan...

That was not the point i was making. Yes it supports Vulkan, but its performance tier is more like the 8800 range of cards.