[Survey] How many of you CANNOT run GZDoom's OpenGL renderer

[GooberMan]

They'd be very hard to find these days.

I'd agree - if we're talking Europe and the US. The Asian market is a substantially different beast though.

Although I suppose G/ZDoom doesn't have that many Asian users.

[Mikk-]

To confirm - yes, GzDOOM runs on Dual 780s in SLI - at 1750~ fps on standard maps. And on the Frozen Time map the game runs at a solid 50 fps on speed rendering, quality reduces the frame rate to approximately 39 fps.

[xenoxols]

I have an i5-3570k overclocked to 4.3 Ghz, and a Sapphire AMD Radeon 7950 which Somehow NEVER goes above 50 degrees Celsius. Even When playing crysis 3 with it overclocked to 1.2 Ghz. I usually get around 2000 fps normally and 80-500 fps on more intensive maps.

[Graf Zahl]

... and that info is perfectly useless in the context of this question. Crysis has been optimized for modern hardware. GZDoom's core is more than 10 years old already so it'll inevitably show some performance issues with lots of stuff on screen.

[Gez]

To provide some explanation to why a 10-year-old renderer doesn't benefit much from the new hardware while much more visually impressive games run smoothly: modern hardware is especially optimized for new, more efficient methods to feed data to render to the hardware; methods that did not use to exist 10 years ago.

It's kind of like wondering why your sled doesn't glide at a hundred miles per hour on the highway, while your sports car does. The highway was designed so that wheeled vehicles could be driven much faster than on a dirt road, but the sled does not have wheels.

[Blue Shadow]

Is there the slightest chance that one day GZDoom's renderer will receive an update to benefit from modern hardware (assuming such an update isn't an impossibility)?

[Graf Zahl]

Hard to say. The update to more modern features is under way but whether it actually makes a speed impact all by itself is doubtful.
The engine is totally CPU-limited at the moment. In the last week I did some work on it, removing the shader overload that had crept in. Although it now runs a shader that contains all options at once I haven't seen the slightest decrease in performance.

What this boils down to is that any attempt at modernization means to dramatically reduce the time needed to process a frame. The actual rendering is only a small part of the problem.

[NeuralStunner]

Given the number of horrific software rendering hacks you have to emulate, I'm not surprised there's so many CPU-load problems.

[edward850]

Actually, most of the load is on the driver end of things. GZDoom has to build a new frame every time it needs to draw something (see: Immediate mode rendering), which ends up being quite a bit a data.
Doom lacks any sort of static structures to cache, being primarily designed around an entirely different renderer and all.

[Graf Zahl]

Actually, most of the load is on the driver end of things. GZDoom has to build a new frame every time it needs to draw something (see: Immediate mode rendering), which ends up being quite a bit a data.

Why does everybody repeat this immediate mode nonsense without verifying?

The problem is not immediate mode - at least not on NVidia - but the fact that in order to generate any data to be rendered the engine has to run a huge amount of code, most of which has nothing to do with rendering but only with traversing the BSP and checking visibility to determine which parts of the level need to be rendered.

With a large level like Frozen Time, ca. 2/3 of the entire time is spent in code that never ever touches the driver interface.

The big problem with the existing code is that it has to make it all work on ancient hardware that needs complex workarounds for all kinds of things which makes optimization of the rendering flow close to impossible. When I can assume to have high performance shading available, a lot of this stuff can be removed. It doesn't directly speed things up but it makes it a lot easier to store some of this stuff statically instead of recreating it each frame.

Of course this means that any optimization will inevitably require quite modern hardware. Having checked the available options I have come to the conclusion that it only makes sense on OpenGL 4.3. Anything less and I'd still be stuck in the same areas that currently stall the engine, immediate mode or not.

[edward850]

Why does everybody repeat this immediate mode nonsense without verifying?

Because whenever the topic of GZDoom's optimization is brought up, immediate mode was always mentioned (even by you). You never really gave a specific explanation until now. At least none that I can find.

[Graf Zahl]

Immediate mode is a problem because it's deprecated, not because it's slow. In fact, for GZDoom's use case with large amounts of extremely small batches it performs a lot better on my Geforce than any traditional buffer method. This has only changed recently with the addition of shader storage blocks and permanently mapped buffers in GL 4.3, that's why until now any attempt of an 'upgrade' would have resulted in an actual downgrade.

[GooberMan]

Immediate mode is a problem because it's deprecated, not because it's slow. In fact, for GZDoom's use case with large amounts of extremely small batches it performs a lot better on my Geforce than any traditional buffer method. This has only changed recently with the addition of shader storage blocks and permanently mapped buffers in GL 4.3, that's why until now any attempt of an 'upgrade' would have resulted in an actual downgrade.

...aaaaaaaand I'd probably be here a while if I was to list everything wrong with this statement.

So I'll pick the easy target here.

Nvidia is quite notorious for putting rubbish in their drivers that isn't to GL spec and claiming that it adds value for their customers. Don't ever use Nvidia hardware to develop and profile a GL standards compliant application.

[Graf Zahl]

Nvidia is quite notorious for putting rubbish in their drivers that isn't to GL spec and claiming that it adds value for their customers. Don't ever use Nvidia hardware to develop and profile a GL standards compliant application.

So I should rather use an AMD card which is so much slower that I'd consider it a total waste of money?
I never had problems with NVidia driver bugs but I had several cases of AMD driver releases causing crashes and one particularly weird one unsetting the write permission of ZDoom's self modifying code segment. No, thank you, NVidia may put rubbish into their drivers - but AMD's drivers actually ARE rubbish.

The way I see it, AMD and Intel take the spec, interpret it literally and implement it badly.
NVidia at least optimizes their drivers and I still use my hardware for playing first and foremost.

[GooberMan]

As a source port author, shouldn't a literal interpretation of the spec be of utmost importance to you? Or should you just admit it and rename the thing NvidiaDoom?

I run Nvidia hardware on my laptop and AMD hardware on my desktop. If my code runs on AMD hardware, there's quite a good chance it will Just Work(TM) on my Nvidia hardware. Why aren't you doing the same?