Doom Comic
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Poor performance in gzdoom
 
Author
All times are GMT. The time now is 07:11. Post New Thread    Post A Reply
PhillHS
Newbie


Posts: 3
Registered: 07-09


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.

Old Post 11-17-13 11:54 #
PhillHS is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6066
Registered: 08-00


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

Old Post 11-17-13 19:20 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
plums
Senior Member


Posts: 1994
Registered: 08-13


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

Old Post 11-17-13 20:33 #
plums is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11140
Registered: 07-07


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.

Old Post 11-17-13 20:56 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 12572
Registered: 07-06


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

Old Post 11-17-13 22:49 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
invictius
Member


Posts: 638
Registered: 03-06


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

Old Post 11-18-13 06:59 #
invictius is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
MP2E
Junior Member


Posts: 157
Registered: 09-07



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.

Old Post 11-18-13 07:24 #
MP2E is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7746
Registered: 01-03



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.

Old Post 11-18-13 09:32 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 12572
Registered: 07-06


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.

Old Post 11-18-13 11:25 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 2119
Registered: 08-03


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".

Old Post 11-18-13 12:22 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7746
Registered: 01-03



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.

Old Post 11-18-13 19:14 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 2119
Registered: 08-03


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.

Old Post 11-19-13 16:44 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
FireFish
Member


Posts: 513
Registered: 04-13


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.

Old Post 11-30-13 16:33 #
FireFish is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11140
Registered: 07-07



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.

Old Post 11-30-13 17:51 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
FireFish
Member


Posts: 513
Registered: 04-13


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.

Old Post 11-30-13 18:00 #
FireFish is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7746
Registered: 01-03


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.

Old Post 11-30-13 18:09 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 12572
Registered: 07-06


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...

Old Post 11-30-13 21:24 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7746
Registered: 01-03



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.

Old Post 11-30-13 22:26 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
the_miano
formerly doomguy93


Posts: 729
Registered: 04-13


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

Old Post 12-02-13 03:30 #
the_miano is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
invictius
Member


Posts: 638
Registered: 03-06



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?

Old Post 12-03-13 08:59 #
invictius is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 12572
Registered: 07-06



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?

Old Post 12-03-13 22:25 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 07:11. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Poor performance in gzdoom

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.