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. So we have wondered about strategy 3 for a while, the idea being that rendering is going to hell on these frames anyway, so maybe recognizing the poor performance and just letting it allocate more cache mid-render is a lesser evil.
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. > 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. -- Larry Gritz l...@larrygritz.com
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
