Difference between performance on Zandronum and GZDoom?

[OliveTree]

This isn't meant to be aggressive or anything, it's more a sincere question (because I'm fascinated by the logic behind this kind of stuff) but why is it that Zandronum seems to run so much better than GZDoom? I understand GZDoom has more available settings, but at the same resolution with all fancy graphical effects turned off GZDoom consistently has a lower choppier framerate than Zandronum, at least in my experience. Assuming they're both branches off of ZDoom, what exactly is the story here? Was there extra attention paid to Zandronum since it has to run well on multiplayer, OR is there a more fundamental overhaul of GZDoom that causes it to run differently that I'm not aware of?

[Dark Pulse]

Probably the latter.

 

I mean, I do know GZDoom is working to get Vulkan support in, and that will definitely improve performance. (It's technically in there now as of 4.0.0, but not quite ready for prime time yet.) But GZDoom is definitely doing a lot more complex things with its graphics engine than Zandronum is, and from what I've read Graf saying, the legacy stuff is also bloating and holding them back a bit, hence why the later 3.x releases had survey code and so on for a few of them, to determine what the new baseline OpenGL Support level should be.

[Graf Zahl]

The postprocessing that has been added throughout 3.x definitely has a performance impact on older hardware, especially on AMD.

That's simply because their OpenGL driver is garbage and has some serious issues with modern rendering features. Zandronum does not use these features because the renderer is a lot older. For current AMD GPUs the Vulkan renderer should solve this problems - with Vulkan AMD performance is on par with NVidia, for older ones not much can be done. Fortunately they are only a small part of the user share but it surely sucks if you are stuck with such a card.

 

 

[OliveTree]

I'd be interested in knowing more detail about why certain video cards have so much trouble with OpenGL, when other real-time 3d engines run fine, but that would require deeper insight into the nature of how video drivers work in the first place and I feel like that's a research trip I'd have to take for myself. If you have any suggestions for resources of that kind that'd be neat, though. 

[Dark Pulse]

3 minutes ago, EtherBot said:

I'd be interested in knowing more detail about why certain video cards have so much trouble with OpenGL, when other real-time 3d engines run fine, but that would require deeper insight into the nature of how video drivers work in the first place and I feel like that's a research trip I'd have to take for myself. If you have any suggestions for resources of that kind that'd be neat, though. 

Basically, AMD simply sucks at OpenGL.

[OliveTree]

2 minutes ago, Dark Pulse said:

Basically, AMD simply sucks at OpenGL.

that seems a bit like its just a rephrasing of 

3 minutes ago, Dark Pulse said:

certain video cards have so much trouble with OpenGL

 

[Dark Pulse]

I'm not the person to go to for technical details, but historically for GZDoom (and even ZDoom to an extent), AMD has simply plagued them and generally ran inferior to nVidia hardware.

 

Graf might be able to shed light onto exactly why, but from what I've read, AMD simply didn't care about compliance with standards and took shortcuts, essentially.

[Graf Zahl]

The main problem is the submission time for GPU drawing operations, what's generally known as "draw calls". The AMD driver blocks the entire main thread until these have been dispatched, NVidia only queues them and dispatches them on a secondary thread. This makes this particular operation 20x slower on AMD and on more detailed maps can have a serious impact on performance because Doom isn't a game that can efficiently batch these together. To get an idea, each linedef is a draw call, each sector plane is one draw call and each sprite or model is one draw call. And since each wall is a single draw call this can really add up to 10000s of draw calls per frame, which on AMD can easily take 15 ms on detailed maps. On NVidia the same operations can be done in less than 1 ms.

 

It's not that AMD didn't care about compliance - that was never the problem - but that the OpenGL state is a very complex thing and apparently very little effort went into AMD's drivers to optimize this part. In fact, it has been a problem even back in 2007 when I got my first OpenGL 3.x capable graphics card, a Geforce 8600. This ran circles around AMD's high end cards with GZDoom.

 

But unlike NVidia who kept their driver in an efficient state, with AMD things apparently got worse. Since modern OpenGL was mostly a barren platform for high end graphics it eventually became clear that this trimmed down OpenGL version performs WORSE on AMD drivers than the ancient OpenGL 2.1! They simply didn't care. And that's one of the reasons why the much simpler Zandronum renderer has better performance on some older hardware.

 

I only can summarize my experiences here that in all the 14 years GZDoom has been existing, there was not a single point in time where OpenGL on ATI/AMD was not a major disappointment. Even back in the very old days GZDoom ran into some nasty driver bugs that never got fixed. Unfortunately, there was no alternative until now.

 

[Gaia74]

2 hours ago, Dark Pulse said:

Basically, AMD simply sucks at OpenGL.

i understand all now ;-;

[Barefootstallion]

3 hours ago, Dark Pulse said:

Basically, AMD simply sucks at OpenGL.

 

AMD sucks period, in my experience.  I haven't owned one of their cards in over ten years.

 

Like, yeah, when a driver update causes a blue-screen-of-death, it's time to question whose card you're using.  I've bought nothing but NVidia cards ever since.  Nothing but great experiences with them, too.

 

There were always performance issues with AMD cards, too.  Games not rendering well, poor framerate, etc.  Never with NVidia.  I will say though, the occasional framerate drop with GZDoom with NVidia does happen.  I always thought it was me just asking too much of my card with what I was doing with my T3 project.  But then I can turn around and play DOOM 2016 on ultra and experience perfect performance.  There was no way that what I was doing with T3 could match the demands DOOM 2016 put on it.  So yeah, there's got to be some performance issues the developers are still working to iron out of GZDoom.

 

As to Zandronum, I don't know.  I haven't put much game time on it.  But there are definitely some issues GZDoom needs to have worked out of it.

[Graf Zahl]

9 minutes ago, Barefootstallion said:

 There was no way that what I was doing with T3 could match the demands DOOM 2016 put on it.  So yeah, there's got to be some performance issues the developers are still working to iron out of GZDoom.

 

Don't be so sure there. It's a vast difference trying to render an old game that was made before hardware rendering became a thing than rendering a modern game that was built around today's video hardware's capabilities.

 

Even with all the refactoring, adjustments for Vulkan etc. the render data GZDoom creates is extremely inefficient and never can drive modern video hardware to use its full performance. Modern hardware works best when you render large batches of polygons with the same properties as a single draw call. But for Doom you end up rendering single walls with a tiny number of vertices each. This is basically the worst thing you can do to modern hardware but it's the only way to process Doom. If you start trying to optimize GPU throughput here you end up wasting even more time and in the end won't get any improvements.

 

[Barefootstallion]

19 minutes ago, Graf Zahl said:

 

Don't be so sure there. It's a vast difference trying to render an old game that was made before hardware rendering became a thing than rendering a modern game that was built around today's video hardware's capabilities.

 

Even with all the refactoring, adjustments for Vulkan etc. the render data GZDoom creates is extremely inefficient and never can drive modern video hardware to use its full performance. Modern hardware works best when you render large batches of polygons with the same properties as a single draw call. But for Doom you end up rendering single walls with a tiny number of vertices each. This is basically the worst thing you can do to modern hardware but it's the only way to process Doom. If you start trying to optimize GPU throughput here you end up wasting even more time and in the end won't get any improvements.

 

 

So I guess what you're saying, is that what we're seeing, is just an artifact of yesteryear technology.  If such is the case, then only 'Oh well' can be said, I guess.  And maybe, heh, someday somebody might stumble onto a solution to fix all of it.

[OliveTree]

So I guess what I'm curious about now is how Zandronum economizes its framerate despite also using OpenGL

[Graf Zahl]

It doesn't. It's just an older renderer that doesn't have a few more modern features that are a bit costly on weaker hardware.

What kind of graphics card do you have? Without that bit of info it's all guessing.

 

 

[Barefootstallion]

GeForce GTX 1050 here.

 

I'm relegated to laptop usage.  Sort of a thing with being a truck driver.

[Dark Pulse]

6 minutes ago, Barefootstallion said:

GeForce GTX 1050 here.

 

I'm relegated to laptop usage.  Sort of a thing with being a truck driver.

For GZDoom, that's more than fine enough.