Page 1 of 1

[r713+]GZdoom OpenGL renderer allocates too much memory

Posted: Thu Feb 18, 2010 2:38
by Major Cooke
I made a separate thread for you, Graf, which is exactly the same as the Zdoom version.

This time I'll go into more depth about what I run, and some commonly used developer cvars. This is with OpenGL renderer enabled.

Zdoom r2108/GZdoom r713

Wads:
-Aeons of Death (v5 beta)
-Hell Revealed II or Invasion UAC

Server cvars used:
-sv_unlimited_pickup 1 - I had always thought that picking up ammo would be useful for getting rid of many floating powerup items, ammo, health, etc... until I ran the task manager in the background one day after updating, and noticed that the more ammo I picked up, the higher the RAM usage was. I don't know why, but this also caused picking up items to gain a small and noticeable freeze in the game before unfreezing. This continued to be a problem, so in an attempt to fix it I turned it off and tested it further, which helped by a small but very noticeable amount.

Now when using this in software mode, it doesn't clamp up the memory nearly as badly, nor lag as much as the OpenGL version.

Maps in particular that have caused a crash:
-Invasion UAC part 5, playing up to map 6 (sometimes), or a bit further. Without unlimited pickup, depending on how many monsters there were, I could usually get to map 11 (or 12, whichever one is the one involving multiple stages of fighting enemies spawning from some portals)

-Hell Revealed II, map 32. Always crashes ranging between 1/4th to half way through killing all nearby enemies, regardless of unlimited pickup. I tried multiple tactics... freezing, flaming, whichever death states had the simplest amount of rendering to do.

Now... Even with the OpenGL renderer disabled, at times it can still crash, but not nearly as bad as with the renderer on. Most of the time, in software I can run through the HRII Playground map without too much trouble, although it can still lag at times (and crash, depending on which bosses spawn...). The software renderer works just about the same as Zdoom's, except for some odd reason on Zdoom's r2071 when I reverted for testing reasons, actually gave me a blue screen while I was playing. I have yet to see this happen in the GZdoom software/openGL renderer and I will let you know if it does happen.

With the openGL renderer on, for testing purposes, I disabled almost all capabilities except for the renderer itself. Shaders, dynamic lights, filtering, all of that stuff is disabled.

Thank you for your time.

Re: [r713+]GZdoom OpenGL renderer allocates too much memory

Posted: Thu Feb 18, 2010 14:51
by Graf Zahl
I have no idea what's wrong with your computer but there must be something horribly wrong with it. When I play this combination of WADs the memory use is almost constant around 250MB regardless how long I play.

What's your full system specs?

Re: [r713+]GZdoom OpenGL renderer allocates too much memory

Posted: Fri Feb 19, 2010 1:17
by Major Cooke
You're probably using Aeons of Death 4.x, if I'm correct. v5 is... well, I can't say it here without breaking beta testing protocols set in place by DBThanatos. If you will allow me to, I can send it in a PM.

"Unable to allocate 21#### bytes from processor heap" is the error message, one time it was something like 1226600 for some reason or another.

I don't expect any sort of problems unless you're using the beta version. 4.x works just fine.

Here's my specs:

Dell XPS M1530
Windows 7 Professional
Intel Core 2 Duo CPU T7500 @ 2.2GHz
Installed RAM: 4.00 gigabytes (3.5 usable)
System type: 32-bit operating system
Hard drive: WDC 150GB SATA
Video card: Nvidia GeFore 8600M GT (upgraded the drivers just three days ago)

Re: [r713+]GZdoom OpenGL renderer allocates too much memory

Posted: Fri Feb 19, 2010 1:45
by Graf Zahl
Well, then I need the never version.

Re: [r713+]GZdoom OpenGL renderer allocates too much memory

Posted: Fri Feb 19, 2010 2:11
by Major Cooke
Alright.

I just got the error again.

"Failed to allocate 1923200 bytes from process heap", but this only happened when I opened the console. Otherwise, it was running fine. Hopefully that and the newer version will give you some clues. I'll get to sending it to ya right away.

Re: [r713+]GZdoom OpenGL renderer allocates too much memory

Posted: Fri Feb 19, 2010 19:07
by Graf Zahl
Well, I'm not surprised that you got problems.

AEOD allocates 500 MB of memory because it just packages tons of huge WADs in a PK3. All these WADs have to be loaded into memory so that they can be used. That means you just wasted 1/4 of your entire application address space!

Now, if you have some background processes running that behave badly and also allocate large amounts of address space (not memory!) you'll quickly reach the point where it no longer works.

Solution: Reorganiza AEOD so that it properly uses the Zip directory structure. Then you'll have magically freed up 450 MB of heap.

I'm not investigating this any further because it's just an extremely bad case of shitty project organization.

Re: [r713+]GZdoom OpenGL renderer allocates too much memory

Posted: Fri Feb 19, 2010 19:47
by Deathlike2
Load what you need when you need it. You are very likely not going to need everything at the same time.

This WAD makes my bytes cry.

Re: [r713+]GZdoom OpenGL renderer allocates too much memory

Posted: Fri Feb 19, 2010 20:08
by Graf Zahl
That's not possible with WADs insizde Zips. I can't access them in a manner that's useful.

Besides, I see no need to support bad project management. If done properly this wouldn't happen.

Re: [r713+]GZdoom OpenGL renderer allocates too much memory

Posted: Sat Feb 20, 2010 2:00
by Major Cooke
Well, it's just been fixed by me... Now it's down to one wad, which is a titlemap. Everything else was booted into the folder system according to the "Using ZIPS as WAD replacements" guide, and indeed it does seem to be behaving better already.

Thanks a lot graf. I'll make sure this never happens again if I can help it...

Re: [r713+]GZdoom OpenGL renderer allocates too much memory

Posted: Sat Feb 20, 2010 2:06
by Enjay
Major Cooke wrote:Now it's down to one wad, which is a titlemap.
and that should be called titlemap.wad and placed in a maps directory inside the zip if you haven't already done that.

Re: [r713+]GZdoom OpenGL renderer allocates too much memory

Posted: Sat Feb 20, 2010 2:09
by Major Cooke
I only left that there because whether DBT is going to change it or not, it's up to him, so I'd rather not mess with that kind of personal stuff (especially since it's his).

However it is already called titlemap.wad, but I didn't think to place that inside the maps directory... *facepalm* My bad.

Edit: Yup, my game is down to 200MB now. Wow... Amazing, Graf. Thanks a lot mate! It's running tons better too.

Re: [r713+]GZdoom OpenGL renderer allocates too much memory

Posted: Sat Feb 20, 2010 4:31
by DBThanatos
Graf Zahl wrote:AEOD allocates 500 MB of memory because it just packages tons of huge WADs in a PK3. All these WADs have to be loaded into memory so that they can be used. That means you just wasted 1/4 of your entire application address space!
Well, to tell you the truth, that's news for me. Unless I missed something on the wiki, nowhere it says someting about that.

And once again, aeod manages to find extreme cases of cluttering problems. And even though it's not a bug per se, now that you mention this, it does help (me/us modders) to know more about resources handling of the engine. Doesnt it? ;)

Re: [r713+]GZdoom OpenGL renderer allocates too much memory

Posted: Sat Feb 20, 2010 8:30
by Graf Zahl
DBThanatos wrote:
Graf Zahl wrote:AEOD allocates 500 MB of memory because it just packages tons of huge WADs in a PK3. All these WADs have to be loaded into memory so that they can be used. That means you just wasted 1/4 of your entire application address space!
Well, to tell you the truth, that's news for me. Unless I missed something on the wiki, nowhere it says someting about that.

I never expected to find a project that has this many resources. The technical issues are mentioned somewhere n the forum but apparently they never made it to the Wiki.