CacheTOP holding more in RAM than it needs/should?

Bugs
1

I’m using a cache for a very utilitarian use case of “pre-processing” some very large image frames and storing the result in a cacheTOP in order to wipe away the ram used in processing. I have the cache set to a size of 1, inactive, replacing single and it appears to eat twice the ram of a single frame of the data. Is this expected or a bug?

Attached tox is what I’m doing, hit the Reload to get the cached image, inside is a comparison of ram usages of a single frame and the cache.

highResLoader_forum.tox (2.1 KB)

I realize I can lock a null instead of caching, just didn’t want to deal with the onSave gymnastics and found this.

2

Hi @archo-p

indeed, it seems that the Cache TOP always takes up memory equal to `Cache Size + 1`

We’ll have a look.

cheers
Markus

3

This is expected since the output texture is different from the cached textures.

4

Gotcha, I understand that Malcolm.

More broadly, I’m curious, is this the current best practice for “caching” the end of a TOP chain that doesn’t involve locking?

I recall seeing various new-ish options on render TOPs that I think were aimed at getting a single render out and not cooking anymore, but I am needing to do image processing after and/or load really big textures first, and so every extra gigantic texture that is avoidable in GRAM would be great.

Thanks

P

5

If these are things processed once, probably the only way right now would be with the Script TOP. You can use the “Modify Outside of Cook’ workflow to push the final texture onto that node. It’ll stay static but not get saved into the project in the way locking does.