Possible memory leaks in 4.4.2

Is there something that doesn't work right in the latest GZDoom? Post about it here.

Moderator: GZDoom Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!

Re: Possible memory leaks in 4.4.2

Postby theleo_ua » Fri Sep 04, 2020 10:26 am

_mental_ wrote:Regarding lags, could you please compare both versions with the following stats enabled in console?
Code: Select allExpand view
stat rendertimes
stat renderstats
stat think


4.5 pre with lags: https://www.youtube.com/watch?v=cA7BYf7v9WM

4.3.3 without lags: https://www.youtube.com/watch?v=hVVpSpfy5r4

NOTE1: It was very lucky try with 4.5 pre, and only 25% of lags appeared (and some long lags, for example before map01 exit, suddenly don't appear), but anyway, there is a lot of difference between 4.5 and 4.3.3 even in these videos (for example map02 exit, map02 lags on the same places near golden doors etc.). Maybe this is because I often clicked PAUSE to explain something. I can create another videos with more and longer lags, if required

NOTE2: I forgot to say in the end of second video about checking RAM usage. But when I watched those videos after recording, I noticed, that memory usage difference is too much - 3.5GB (4.5pre) vs 400MB (4.3.3), so please pay attention to this

NOTE3: youtube provides low bitrate for 720p quality, so if you dont like blurry artifacts, please change youtube player settings to 1440p (or 1080, if 1440 still not available), because for 1440 youtube give enough bitrate for same video quality, as in my HDD during recording
User avatar
theleo_ua
 
Joined: 07 Feb 2016

Re: Possible memory leaks in 4.4.2

Postby drfrag » Fri Sep 04, 2020 1:12 pm

Seems upscaled textures now take up much more ram. Certainly there was a recent major refactor of the upscaling code.
https://github.com/coelckers/gzdoom/com ... 9797c9c32c
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Possible memory leaks in 4.4.2

Postby theleo_ua » Fri Sep 04, 2020 5:25 pm

drfrag wrote:Seems upscaled textures now take up much more ram. Certainly there was a recent major refactor of the upscaling code.
https://github.com/coelckers/gzdoom/com ... 9797c9c32c


I tried to understand, why new code should take 9x more RAM, but didn't get it. But found next:

Still not solved: Material layers need explicit control, not only for scaling but also for filtering.


1) Does this mean, that after solving this "Material layers need explicit control also for filtering" issue, RAM usage will come back to 4.3.3 low consuming style?

2) If I change to vulkan instead of OpenGL (I mean future (with full vulkan support without critical issues) poilshed versions, not current), will it take less RAM?

P.S. I tried to change OpenGL to Vulkan in GZDoom settings (for 4.5pre), and GZDoom crashes during loading of map01:

Execution could not continue.

Could not submit command buffer: device lost


Here is crash report: https://u.pcloud.link/publink/show?code ... Vd2yizh4dk
User avatar
theleo_ua
 
Joined: 07 Feb 2016

Re: Possible memory leaks in 4.4.2

Postby vsonnier » Sat Sep 05, 2020 12:52 am

I tried to understand, why new code should take 9x more RAM, but didn't get it. But found next:


I didn't find the reference, but in the new code ALL (* not quite, see below) textures are upscaled, while in the previous versions the additionnal texture pack textures were never resized because considered already "high resolution". To be confirmed, but it could explain the RAM/ VRAM inflation.
Indeed if I use my favorite texture pack in 4.5 the textures are clearly affected by the option "Resize textures" with xBRZ 2x depending on ON or OFF while it was never the case in (some, which one ?) past version.

* There is a CVAR option controlling the max texture size to be resized (no need to resize already high enough resolution) : gl_texture_hqresize_maxinputsize = 512 (by default)
which means the texture is NOT resized if height * width > gl_texture_hqresize_maxinputsize * gl_texture_hqresize_maxinputsize.

Give a try to reduce gl_texture_hqresize_maxinputsize to see if affects RAM consumption.

You can also get a hint in Vulkan VRAM consumption by using 'vk_memstats' on the console.
vsonnier
 
Joined: 11 Apr 2019
Github ID: vsonnier
Operating System: Windows 10/8.1/8/201x 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Possible memory leaks in 4.4.2

Postby _mental_ » Sat Sep 05, 2020 2:41 am

theleo_ua wrote:2) If I change to vulkan instead of OpenGL (I mean future (with full vulkan support without critical issues) poilshed versions, not current), will it take less RAM?

Please stop posting nonsense about major issues with Vulkan renderer. The only important thing it doesn't do at the moment is graceful handling of out-of-VRAM condition. Apparently, you encountered it with all these high resolution textures.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Possible memory leaks in 4.4.2

Postby theleo_ua » Sat Sep 05, 2020 2:58 am

vsonnier wrote:Give a try to reduce gl_texture_hqresize_maxinputsize to see if affects RAM consumption.


Tried with gl_texture_hqresize_maxinputsize=256 and even gl_texture_hqresize_maxinputsize=32, and lags + ram consumption was the same. I think that something is broken in the code, so gl_texture_hqresize_maxinputsize is ignored and textures are resized always (so taking too much ram)

Also I noticed next in my config:
gl_texture_hqresize_maxinputsize=512
gl_texture_hqresize_mt_height=4
gl_texture_hqresize_mt_width=16

I wonder, what hqresize_mt_width mean and why it 16

vsonnier wrote:You can also get a hint in Vulkan VRAM consumption by using 'vk_memstats' on the console.


Thanks, will use it when vulkan will work with my config and mods

vsonnier wrote:* There is a CVAR option controlling the max texture size to be resized (no need to resize already high enough resolution) : gl_texture_hqresize_maxinputsize = 512 (by default)
which means the texture is NOT resized if height * width > gl_texture_hqresize_maxinputsize * gl_texture_hqresize_maxinputsize


Interesting idea, but I think it should be expanded with something like this:

Add next options:

1) HQ rescale all textures
values: on, off, mod defined
("on" means, that next options (from 2 to 7) will be ignored)

2) dont HQ rescale textures in HIRES subfolder (on, off)

3) dont HQ rescale textures with more than X pixels count (on, off)
pixels count (integer)

4) dont HQ rescale textures with more than Y width (on, off)
width (integer)

5) dont HQ rescale textures with more than Z height (on, off)
height (integer)

6) dont HQ rescale textures, which are mentioned in texture black list file in the mod (on, off)

7) HQ rescale only the textures, which are mentioned in texture white list file in the mod (on, off)

By saying "textures" I mean textures, sprites, patches etc (at least which are located in HIRES folders/subfolders)

_mental_ wrote:
theleo_ua wrote:2) If I change to vulkan instead of OpenGL (I mean future (with full vulkan support without critical issues) poilshed versions, not current), will it take less RAM?

Please stop posting nonsense about major issues with Vulkan renderer. The only important thing it doesn't do at the moment is graceful handling of out-of-VRAM condition. Apparently, you encountered it with all these high resolution textures.


So Vulkan is ready to use now (if not taking to account memory issues you explained)? Then sorry, somehow I missed this
User avatar
theleo_ua
 
Joined: 07 Feb 2016

Re: Possible memory leaks in 4.4.2

Postby drfrag » Sat Sep 05, 2020 3:54 am

vsonnier wrote:o be confirmed, but it could explain the RAM/ VRAM inflation.

No, it also happens with the test mod the OP attached and it doesn't contain hires textures (but i haven't confirmed it myself). There must be a problem in the new upscaling code.
About Vulkan yes it's ready to use but due to the out of vram issue it's not recommended to use it with HQ resize modes (BTW i never use those modes myself and they've introduced a lot of problems specially in the software renderer).
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Previous

Return to Bugs

Who is online

Users browsing this forum: No registered users and 1 guest