Poor performance in gzdoom

Hi all,

I'm suffering really low framrates in gzdoom at some points, it's particularly noticeable in nuts, but also in some of the megawads I've been playing (map 27 of Slaughterfest 2012 for example, which has over 10K monsters).

The odd thing is for most levels I don't seem to have a problem.

System specs :

AMD FX-8120, 8GB RAM, AMD Radeon HD6850, Windows 7 64 bit.

The think is it used to run on my old system (also an AMD CPU, but with an Nvidia 8800GT graphics, though that was 32bit XP).

Cheers.

Phill.

I can almost guarantee you this will get blamed on the 6850.

Something to do with shaders maybe? What kind of settings are you using?

Both ZDoom and GZDoom tend to be slow when thousands of monsters are active at once. You might want to try GLBoom+ for such maps.

Even better, try a software-rendered source port on those same levels. You might be surprised by the results.

Core i7 870 @3.85ghz, geforce 560 here. Also very jerky, even on 640x480.

invictius said:

Core i7 870 @3.85ghz, geforce 560 here. Also very jerky, even on 640x480.

Jesus, I guess GZCrysis has finally come out.

In all seriousness, I hope this is just a simple performance regression.

invictius said:

Core i7 870 @3.85ghz, geforce 560 here. Also very jerky, even on 640x480.

That's odd. I got a similar system, just a bit weaker and it runs super-fast. Overall it's correct, though, that ZDoom's play engine has problems with such large amounts of monsters. It has nothing to do with the renderer, though. There's something in the play code that's stealing the time.


Can it be that the latest drivers got messed up? I haven't updated mine for over a year now.

Some OpenGL drivers just aren't happy with all that sprite pushing, and the bottleneck might become OpenGL rendering itself. There was an old thread which showed how in timedemos of nuts-like levels, the software rendered version of ZDoom (and prBoom+) beat GZDoom and glBoom+ fair and square, sometimes even with a factor of 3:1 or more. Things might have changed since then, but it once was a valid point which might be worth considering. The very least, can the OP post a benchmark between ZDoom/GZDoom for the same level, same conditions? Perhaps with recording a timedemo.

Something one must always bear in mind with such a comparison is how efficiently elegant the vanilla software rendering algorithm is. Certainly there are some less than optimal areas, given particular video modes but for the most part it is very well optimized. The flat flooding algorithm, for example, will often outperform a GL solution which has to pump triangles through a general purpose rasterizer. It stands to reason that at certain resolutions and with specific map geometries, vanilla will outperform even highly optimized hardware GL renderers given a half-decent CPU. And thats not a "cop out".

DaniJ said:

Something one must always bear in mind with such a comparison is how efficiently elegant the vanilla software rendering algorithm is. Certainly there are some less than optimal areas, given particular video modes but for the most part it is very well optimized. The flat flooding algorithm, for example, will often outperform a GL solution which has to pump triangles through a general purpose rasterizer. It stands to reason that at certain resolutions and with specific map geometries, vanilla will outperform even highly optimized hardware GL renderers given a half-decent CPU. And thats not a "cop out".

I don't think that this has any merit these days. If you just create a vertex buffer for each sector and render it all in one go there's no triangle pushing left.

This isn't in GZDoom's release code but I once did some tests with it and it brought some nice speedup - the only problem being that it all becomes rather useless once dynamic lights come into the picture. Of course, even that may have changed with more modern hardware.

On my system at least GZDoom handily outperforms the software renderer on any maps I tested with so far.

On modern hardware, yeah. Like I said it depends on the system in question. My main point being that for its time it was pretty efficient.

i suspect that a lot of OPENGL source ports for doom use 'direct rendering' which is never used for advanced graphics rendering by any modern up to date game company.

FireFish said:

i suspect that a lot of OPENGL source ports for doom use 'direct rendering' which is never used for advanced graphics rendering by any modern up to date game company.

That's because direct mode is not adapted to the much higher level of complexity used by modern up to date games. For relatively simple geometry like the typical Doom level, the supposedly higher performances when rendering aren't enough to compensate the greater overhead. Graf experimented a bit with VBOs but it generally didn't give enough of a performance boost (in fact, it was even slower in some cases) to merit pursuing the renderer rewrite further.

thank you for the clarification.

it is kind of interesting to read that non stop cpu usage to stream all the 3D data to the graphics card, is faster for simple doom and doom 2 geometry instead of doing one big stream, and letting the card handle the rendering from there on.

edit : typo removal, sentence correction.

The problem is simply that the CPU won't deliver enough data to make the GPU run at full load. It's sitting idle for most of the time. On modern hardware GZDoom is strictly CPU bound so obviously any approach that requires more CPU power will be slower.

Of couse my tests were made 5 years ago and the approach I used wasn't the best so some slight speedup is certainly doable. But since most of the time is not spent rendering but processing the data on the CPU side (i.e. tasks that'd still have to be done when using vertex buffers) there's only little room to gain.

With complex enough map geometries, just performing the standard Doom's BSP traversal at each tic can become a significant portion of the total used CPU time. Adapting the visuals to OpenGL on top of that certainly isn't cost-free, and there's a "break even" point above which you lose just as much if not more by going OpenGL/3D than if you just left everything software rendered. And that's without counting enemy logic and visible sprites...

Maes said:

and there's a "break even" point above which you lose just as much if not more by going OpenGL/3D than if you just left everything software rendered. And that's without counting enemy logic and visible sprites...

Sorry, but here I disagree. I've yet to see a map that renders slower on GZDoom with hardware rendering than on ZDoom on my machine, unless some weird hacks (like the skybox windows in Super Sonic Doom) are used.

About the BSP traversal you are correct, of course. Streamlining the renderer may help on AMD cards, though, because they spend a lot more time inside the GL driver but on NVidia the maximum possible speedup would be around 10-15% maybe, because that's normally the time being spent in the actual code that transfers the data to the driver - and even most of that can't just be omitted, it just has to manage the vertex buffer and upload that later.

Nuts.wad will not run properly on either zdoom, gzdoom, skulltag, or zandronum. It is meant to be run on Boom.

doomguy93 said:

Nuts.wad will not run properly on either zdoom, gzdoom, skulltag, or zandronum. It is meant to be run on Boom.

What is it about zdoom that causes this?

doomguy93 said:

Nuts.wad will not run properly on either zdoom, gzdoom, skulltag, or zandronum. It is meant to be run on Boom.

I think this only applied to old versions of ZDoom. E.g. ZDaemon can handle survival maps with monster hordes just fine (unless they really overdo it, like maps with multiple Icon of Sin spawners that get to 20000+ monsters in a few seconds)

Even some version of prBoom+ couldn't handle it well, which turned out to be a MBF feature (something about "friend aid" or somesuch) which caused an O(n^2) degeneration of the gameplay code. Ironically, simpler sourceports without MBF features just require a linear increase in CPU power to handle an increased number of monsters (assuming other limits don't break first). E.g. I was surprised to find that Mocha Doom ran nuts.wad just as well as prBoom+, and significantly better than ZDoom and plain prBoom O_o

However, as soon as you turn on anything OpenGL or Direct3D, the tables might be reversed once more: in addition to the gameplay code itself, you add another potential bottleneck (the OpenGL pipeline). YMMV depending on rendering code, driver revision, OS and GPU, of course, but in general an improvement in performance is not a given in maps with extreme visuals. E.g. even if you can play nuts.wad in GZDoom "fine", I dare you to do it with full GL lights on....yup, not so great now, huh?

Sorry for reviving old topic but I found an unexpected solution to this same problem with my Radeon Mobility 4650 video card.

Long story short: close Catalyst Control Center on the taskbar...

I have Win XP SP3 now, I closed all other programs that were running (Chrome and VLC Media Player) and ran Gzdoom. Slowdowns were the same, getting 5 to 6 fps on any Pirate Doom map where there is a wide open area with lots of architecture features. Unplayable. Disabling everything wouldn't solve it, resizing to low-res wouldn't either.

THEN, I had the idea of closing Catalyst Control Center on the taskbar, as someone mentioned on another tech support forum.

BOOM! Just closing CCC stopped with all the slowdowns! I use an external program to cap my fps to 30 called DxTory (so my GPU temps remain under control). Future experimentation showed that after closing CCC, I can run GzDoom alongside other programs without any problem or slowdown. Another proof that ATI sucks major ass! Avoid ATI video cards as hard as you can. Not the first game which has ATI-exclusive problems.

Modern AMD drivers are a lot better. I think most of your problems can be attributed to running XP and along with it some rather old and obsolete drivers.

Gonna use the opportunity.

I'm getting a noticeably better performance in 1.9.1 than in 2.4.0 with the same map and resolution. CCC trick didn't help. Some things I can't run in 1.9.1, so it bothers me. Specs: http://support.hp.com/us-en/document/c01805648

You are the second person who says that 1.9.1 performs better on AMD/ATI.

I suspect that they somehow managed to optimize the legacy render interface, but GZDoom does not use that anymore, it has completely switched over to using vertex buffers. But due to Doom's nature, it uses that with low vertex count batches and it seems like that particular usage scenario falls through the cracks.