Lagging and Crashing GZDoom for last couple of versions

[eharper256]

I've had some serious GZDoom performance issues recently in the last two builds (3.4 / 3.5) where it takes increasingly long to load (30-40 secs) to load a fresh save from the menu, I get freezes up to 5 seconds long when several things are happening on screen, and I get kicked to desktop with no explaination sometimes. This appears to have worsened in 3.5. When looking at the task manager, GZDoom appears to be using rather extreme amounts of my RAM (All 6.4 GB or so that's free in many cases) when running.

Finally, one of these kicks decided to generate a Crash Report, so I've put that zip up for access here on MEGA.

Playing Brutal in this case, with SinSeven megawad, but I've had similar issues with playing Trailblazer, Guncaster, and even Vanilla; with all sorts of megawads. And I've not had problems with mods or pwads before.

My system is aging but is still a semi-decent gaming rig (i3-4130 3.4 Ghz dual core, 8 Gb of Ram, AMD R9-270, Windows 7) usually able to run modern stuff in 1080p on Medium/High.

[_mental_]

The crash is inside AMD driver. What's the version you have?

[eharper256]

Windows calls it: 23.20.15033.5003
Inside Radeon Control Panel it is Adrenalin 18.3.4
From the 22-03-2018 update.

Guess I'll update the drivers, but its not a terribly old version, and I've not seen any other games cause havoc.

[eharper256]

Updated to the latest stable AMD driver 18.5.1.
Also gave the PC a clean-out of dust (wasn't too severe, was last done 6 months ago) just in case.

Loaded last save from this megawad with same conditions as before; same old 50 odd seconds loading, and then crashed again before it even managed to render the level.

New Crashreport is here: https://mega.nz/#!Ed8iWSJY!XW2zb8JrQEEH ... opAMW4cEy8

[_mental_]

It's still crashing inside AMD driver. Could you please try to start GZDoom without all this "stuff"?

[eharper256]

Hmm. In the end, I regressed to 3.41 to finish the level from the save, which took a very long time to load (about 1 minute) but eventually co-operated enough to play (and I cleared the gibs using Universalgibs as soon as I got in, which helped a bit). I'm just assuming that this specific combo of things was overloading the system.

I then tried a bunch of things. First of all, loading vanilla except hi-rez textures and brightmaps. Loading was almost instantaneous for map 01.

However, I didn't actually realise initially that this specific megawad already had weapon and monster replacements! In any case, I played through the first level briefly and there was no issue. Out of interest, I also used IDCLEV to get to the troublesome final level. It appeared fine this time, loading quickly (>3 secs) and without issues.

Hence, I figured it was clearly the fact that double-weapon and monster replacement was going on in a complicated map full of items and weapons. I tried the same proceedure with all mods on except Brutal, and sure enough, it loads quickly, and only adds negligible load time (un-noticeable, probably 1 sec or so difference). Then tried Trailblazer; and startup was a bit slower and with the IDCLEV to the final level, again took a fair while (20 secs?) to get there.

So yeah, apparently my GPU is croaking out when having alot of replacements upon replacements; and apparently 3.50 is possibly adding more strain? Strange, but plausible I guess.

[Graf Zahl]

So yeah, apparently my GPU is croaking out when having alot of replacements upon replacements; and apparently 3.50 is possibly adding more strain? Strange, but plausible I guess.

That's actually very possible, if you run the older build without render buffers. Those are always on in 3.5

[phantombeta]

Just to be sure, do you have "Precache GL Textures" enabled in GZDoom? (it's in Options>Display Options>OpenGL Renderer>Texture Options)
I've encountered someone else before who had long loading times in GZDoom when playing mods like Trailblazer and Guncaster before, and disabling that fixed it.

[Graf Zahl]

Actually, if mods have precaching issues it's a sign that the mod is doing something wrong. With Guncaster there was some quite large problem with bad sprite definitions that not only caused precaching delays but also lots of memory wastage.

[eharper256]

Yes, I did have gl_precache=true in my ini.

I set it to false, and repeated the same proceedure above with Trailblazer.

...
HOLY HELLS BELLS.
Instantaneous Loading, even using IDCLEV to get to the previously troublesome level. Resource Manager is also calm on my RAM as well, only using about 500mb for GZDoom rather than multiple gigs!

Wow. I wouldn't have thought pre-caching anything could be bad. But apparently so. You learn something new every day I guess.

[Graf Zahl]

If precaching crashes your GPU it's a good indicator that there's indeed a problem with it. Since it uploads a lot of textures all at once it will put to some hard work for that in a very short time.

[phantombeta]

If precaching crashes your GPU it's a good indicator that there's indeed a problem with it. Since it uploads a lot of textures all at once it will put to some hard work for that in a very short time.

Or, more likely, based on the OP, the driver or GZDoom is outright running out of memory.

[wildweasel]

Does OP have any of the HQ texture filters enabled, or is Multisampling raised too high? I once had the NVIDIA driver kill GZDoom because it was running out of VRAM, and I later found out that was because Multisampling was set at 32x, which a 1 GB card could not keep up with.

[Graf Zahl]

Yes, that may also be responsible. Sadly, OpenGL has no useful facilities to detect and handle this case. With Vulkan I could just error out or force texture scaling off if the engine runs out of video RAM.

[eharper256]

It's a 2GB card. I only have Multisampling at 2x, and anisotropic at 4x. But I do have HD4x High Quality Resize on. Maybe I should calm that down if it makes a difference; though again, if that's the case I didn't realise effectively blurring the sprites slightly would have such an intense effect on the GPU.