In the context of our renderer, our scenes quite often reference 1-2TB of total texture, and we use a 4GB cache. That is almost always enough, the portion of redundant reads is pretty low (maybe ~10% more reads than ideal if we had infinite space) and we are using it pretty heavily. But for a very small minority of scenes, quite rare really, we can get into a pathological access pattern where we end up reading much more texture than we're using and render times are bad.Yep, this aligns almost exactly with our typical texture I/O patterns as well.
That's a fair point. However, I do think the amount of free RAM would be an important consideration as well (I know that can be somewhat tricky to detect depending on the platform).I suspect that once we get into that situation -- and assuming that bumping up the cache size helps -- I would anticipate that the troublesome access pattern probably continues for the whole renderer, so I just assumed that there was no real point to trying to "contract" the cache again.
If you're barely flying under the ceiling (or have even gotten close enough to start paging out assets from a host application, etc.), a sudden request for 2 more GB of RAM may just end up thrashing the entire system, instead of just the texture cache.
-Nathan
On Nov 12, 2021, at 2:47 PM, Nathan Rusch <nathanru...@gmail.com> wrote:
Yeah, I think it would be more complex. I guess I've just been imagining that any application that puts even a moderate amount of stress on the cache would likely end up triggering the growth mechanic. Maybe the idea would be for the detection algorithm to be fairly heartless, but still, as a user of the API, if the cache size only goes in one direction, then it seems like I might as well just use a static cache at the "hard max" threshold and call it a day.
To frame this another way, if I know I have enough memory to let the cache grow into, then I might as well just allocate it to the cache up front. Otherwise, if I gamble with a variable-sized cache and the growth exceeds the amount of free RAM, I think the end result would be a lot worse than a thrashed ImageCache that would otherwise still fit in RAM.
That said, there's a very real chance I'm not considering enough applications though, since most of my experience with ImageCache is in the context of 3D rendering.
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
