Question on texture memory usage

[SneaksieDave]

I was just reporting an issue about a possible memory leak in texture loading and/or flushing when it occurred to me, "do these numbers make sense?" Rather than assume something's wrong and report it, I wanted to get some feedback first.

 

If you open the issue mentioned above, see that an example run (open Media tab, load all bricks textures, then go to the Textures tab (no need to scroll it)), produces the following typical memory demands (Mb, total):

 

150 -> 267 -> 330

 

After the baseline 150, loading all of the bricks textures consumes 117 Mb. Opening the Textures tab then consumes another 63 Mb. Does this make sense? I don't presume to know what's going on behind the scenes, all the file and memory handling, etc., but I only ask because from the outside, I'm guessing there could be something amiss. Here's why: the _ed.jpgs in that folder, numbering 58 in total, are only 1.21 Mb in size, total. If you consider their memory imprint, PSP reports the typical image (256X256) as consuming 192kb of memory. Multiplying 58 files X 192 kb gives a little less than 12Mb total. Does this make sense, considering the 117 Mb result of loading them, and then the 63 Mb more required for the Textures tab?

 

I know DoomEd is a completely different beast, but check this out; it handles the task with much less memory (this is in Kb, because I needed to go down to that resolution; you'll see why):

 

138,140 -> 139,428 (!) -> 228,920

 

Admittedly, "loading" (step 2) of the textures could be a completely different action in DoomEd and DR. Whatever it is though, it takes only 1288Kb of memory! Recognize that number? It's very much like the 1.21Mb size on disk. So it's easy to assume DoomEd loads them and leaves them in compressed jpg form. Then, opening the Textures tab takes about 90Mb. So perhaps that much really is necessary to display images (hey, what do I know). But the end result is: Doom3 loaded and displayed them in about 90Mb, while DR did it in double that, 180Mb. That number is very suspicious. Hypotheses 1, 2: Could the images be redundantly doubled in DR's memory handling? Or, could DR be failing to make use of video card memory?

 

Once again, I only raise this because of the disparity in behavior and the suspiciousness of it all. If something is found in the speculation above, and fixed, it may halve DR's memory reqs!

 

Edit: Further info: if I load the images in DR one by one while watching memory, it can be deduced that it sets a few Mb aside, loads some textures into it, sets a few more aside, and repeat (standard stuff). This is because you can load four or so materials in a row with only very small changes in memory. Then, it jumps perhaps 6Mb, and repeats. But sometimes, it jumps 6Mb, then another 4Mb, then a bit more, then goes back to small jumps. I've checked images which were causing this and they do use the small versions, so there's nothing suspicious about them. Hm. I also note that the average diffuse size in that same brick folder is ~1.7Mb. That, times 50 files = almost 90Mb; half of the DR req, and all of the D3 req. If the other crazy notion from above (redundant copy in memory) is completely batty, here's another highly unlikely one, Hypothesis 3: could DR be loading the JPGs as intended, but actually allocating memory for them based on the diffuse sizes? Far out, I know, but it doesn't sound quite so crazy if you think about that DR knows the dimensions of the diffuse image (shown in the Media tab, material description) from somewhere. If it's only loading a low res _ed version (256^2), how does it know the actual diffuse is 1024^2, unless it actually inspects it? And so, the leap: could this be the cause of such a problem, resulting from leftover/legacy/WIP material loading from way back in GTK's development, which was never quite brought up to date?

 

Anyway, just more black box speculation. It has occasionally led to interesting discoveries at work.

 

Edit: Maybe it IS that! After I posted here, I did some stuff with photoshop, firefox was already open, etc., i.e., it screwed with my windows page file. I tabbed back to DR, and noticed that its old memory imprint (~400Mb) was now only ~115Mb. So, I guess windows put it into 'low need' mode. My speculation is that makes DR's memory situation much more... sensitive, to new changes. Most of it is being paged, so if I load new textures, it will have a full, very apparent effect on the memory imprint. And lo and behold, it did! With all of wood/boards and wood/panels loaded (previous experiment), I went to stone/natural. And son of a bitch, every 512^2 material I loaded changed the memory imprint by 1.4Mb! Every 1024^2 material, 4Mb! This is right in line with the size of the full diffuses. What's going on here? If it's only loading a 19kb (disk size) file requiring 192kb of memory, why does it allocate (and use?) 1.4Mb? 4Mb? I have confirmed that it is in fact the _ed versions showing in the editor (I defaced only the _ed version ), but the memory it uses is that of the full sized diffuse!

 

?!

[SneaksieDave]

I have filmed a movie of what I'm describing above. I might just not know how all of this works, but I'm sure hoping I struck QA gold here. If not, I gladly accept being shot down. It's been fun either way. Watch the vid (I have no idea why conversion to WMV changed the aspect, but it doesn't matter, it's readable):

 

http://208.49.149.118/thedarkmod/temp/memory.wmv

 

1. I start out with a 101Mb baseline.

2. I click a 1024 image, and the memory increases by ~5Mb.

3. I click a 1024 image, and the memory increases by ~6Mb.

4. I click a 512 image, and the memory increases by ~1.5Mb.

5. I click a 512 image, and the memory increases by ~1.2Mb.

6. I click a 1024 image, and the memory increases by ~5Mb.

7. I click a 512 image, and the memory increases by ~1.5Mb.

8. I click a 512 image, and the memory increases by ~1.4Mb.

9. I click a 512 image, and the memory increases by ~1.3Mb.

 

These images and materials were inspected. The materials all use the _eds; the _eds are all small (~20-30kb) JPG files. The fact that it knows the diffuse dimensions (shown in description) makes me the most suspicious.

 

It's loading the editor versions, but allocating memory as if for the diffuses.

[greebo]

Thanks for your effort, SneaksieDave, muchos appreciatedos. Maybe I can find some time today to investigate this, I think I know already what could be the problem here.

[Tels]

Fascinating, Dave. We might have created a few thousand JPGs in vain if the editor allocates the memory wrongly

 

 

(Another theory is that it creates a 1024x1024 in-memory texture and then loads and decompresses the 256x256 JPG into this texture to use if for rendering. Sounds crazy, but in software, nothing is

 

Let's see what greebo turns up and what the problem really is.

[greebo]

I've disabled the diffusemap dimension display in the MediaBrowser's info widget, so the effect SneaksieDave observed is now gone. Maybe I can find a better way of determining image dimensions without opening the image, or I implement a dedicated button "Show Image Sizes" which lets the user control which shaders get fully loaded.

 

I've got a new pre-release build here for further tests:

 

http://208.49.149.118/TheDarkMod/DarkRadia...t-0.9.7pre8.exe

[SneaksieDave]

So there might actually be something to this, woot.

 

I've tried the new snapshot, and I do still get a lot of big memory allocation. I'm not sure what the heck is going on; if you watch the attached video, on several of the clicks, it goes up a very tiny amount (the amount of the image file itself, even), making me hopeful, but then for just as many or more other clicks, it goes up the telltale ~1.4Mb or ~4Mb. In my sparse knowledge, I'd guess that an occasional big chunk is like a database growing, but what is it when it's a bunch of them in a row, and far beyond need? And, why should the bricks folder, described above, take so much memory? As a parallel example I checked a load of saintlucia; it still takes about 1.2Gb as before.

 

http://208.49.149.118/thedarkmod/temp/mem2.wmv

 

I so hope this turns out to be a fixable issue. It would represent immense memory savings! It'd probably need even less memory than DoomEd, since DR doesn't do all the realtime and game-related stuff it does.

[greebo]

The issue that DarkRadiant is generally using too much texture memory is a different one. I only fixed the issue with the Media Browser, which is completely independent of the overall texture loading stuff.

 

One at a time. I'm currently investigating other bugs (one two annoying physics issues and that bug with DarkRadiant losing ESC deselection functionality that several people have reported recently and which just cropped up on angua's machine).

[SneaksieDave]

The issue that DarkRadiant is generally using too much texture memory is a different one.

Okay, I'll update the tracker with a formal entry.

Edit: http://bugs.angua.at/view.php?id=704

 

I only fixed the issue with the Media Browser, which is completely independent of the overall texture loading stuff.

Oh, I didn't know there was a problem there(?) I assumed it was behind the wrong size allocs, but apparently not (or maybe it's part of it)?

[Domarius]

If it's only loading a 19kb (disk size) file requiring 192kb of memory, why does it allocate (and use?) 1.4Mb?

It could have other problems, but this specific example, have you factored in the decompressed size of a bitmap? (Resolution multiplied by colour bit-depth)

[SneaksieDave]

If it's the same as the non-editor, full version of the file, something's got to be wrong somewhere, or editor versions make no sense / offer no benefit. In fact, they offer detriment, because they look worse, are extra work, and use extra files / HD space. The same files loaded up in DoomEd use a fraction of space too, so that's more evidence something is wrong. Finally, DR behaves sporadically in this matter, sometimes acting just like DoomEd (tiny allocs at a time) and other times, huge spikes in memory for no apparent reason.

 

Anyway, it seems pretty much accepted that something is amiss.

[OrbWeaver]

If it's the same as the non-editor, full version of the file, something's got to be wrong somewhere, or editor versions make no sense / offer no benefit.

 

The _ed versions are actually very useful for me, when I want to browse the textures directory with a file browser and import images into Blender in order to UV map a piece of architecture with a stock texture. Since tga versions of the diffusemaps are not available, and neither Nautilus nor Blender can load DDS (afaik), it would be impossible to do this if the editor versions were not there.