Possible memory leaks in 4.4.2

[theleo_ua]

Regarding lags, could you please compare both versions with the following stats enabled in console?

Code: Select all

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

[drfrag]

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

[theleo_ua]

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

[vsonnier]

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.

[_mental_]

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.

[theleo_ua]

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

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

* 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)

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

[drfrag]

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