It seems to me that if the control was exposed, it should be safe to adjust it
up or down after the ShadingSystem has been created. I'm not sure I'd advise
doing it while buckets are rendering (and thus possibly in the middle of
executing actual texture lookups), but certainly in any pause of activity (say,
between progressive refinement passes or rerenders) should be fine.
Note that the result will not be instantaneous. What would happen is that next
time a tile was needed that was not in cache (which, conceivably, might not
happen for a while, or ever, if the "working set" happens to already be in
cache), it would only then check the cache size limit, in order to know if
loading the new tile should entail kicking an old tile out of the cache.
Ordinarily, kicking out any one existing tile is probably enough to make
sufficient room for the new tile, but if it suddenly found that the limit was
way lower than last time it did the check, I guess it would just kick tile
after tile out until it got within the new budget.
I suppose if this were important, we could rig it so that a downward change of
the limit would immediately trigger a call to the check_max_mem that kicks
tiles out of cache of it's over-budget. But currently it only checks this when
new tiles are added to the cache.
-- lg
On Feb 18, 2015, at 8:43 PM, Thiago Ize <[email protected]> wrote:
> I believe this should be safe to do on the fly. Right now, however, it looks
> like arnold doesn't give you this ability since the max_memory_MB attribute
> is only set upon render startup. For this to work, the arnold core would
> have to be extended to support this.
>
> On Wed, Feb 18, 2015 at 7:53 PM, Chad Dombrova <[email protected]> wrote:
> We use arnold for rendering, which uses OIIO for texture caching. A common
> conundrum we face is what size to use for the texture cache. Too small, and
> we get massive amounts of redundant IO read, which kills render performance.
> Too big, and arnold and the cache combined might consume all available memory
> and go into OS swap, at which point you might as well kill the render.
>
> If we accept that swap is the equivalent of render death then it would
> behoove a renderer to free some non-critical memory to avoid this. For
> example, dynamically reducing the size of the texture cache. Hypothetically,
> this would purge the oldest tiles until the reduced size is achieved
> (presumably using the same method already used for determining what tiles to
> purge when the cache maxes out. FIFO?). There would also be a min cache
> size, which arnold would use prevent reducing the cache to zero.
>
> So, the question: is it currently possible to reduce the size of an existing
> OIIO texture cache?
>
> And also: is this a horrible idea?
>
> -chad
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
