Exactly. When you see that the amount read from disk is several times the total
texture referenced by the scene, you know you must be thrashing the cache.
It is usually not necessary to make the cache anywhere near as big as the total
of all the textures. There is usually a tipping point, significantly less than
this, where some tiles may be read multiple times, but not enough to really
slow things down. But anything above that and you slow to a crawl. Just like
with virtual memory on any computer system -- a little swapping is actually
very efficient, it's *thrashing* (where nearly every memory access requires
something to be paged in) that is unbearable.
It's often the case that having an in-memory cache that's 10% or even
significantly less, compared to the total texture size, gives performance that
is within a few percent of having a cache that's big enough to hold the whole
texture set.
If you have memory to spare, by all means make the cache as big as you want.
For us, we're trading against memory for the geometry of big scenes, and the
texture system is much more amenable to being squeezed for space without
trouble, we just can't easily do the same for geometry.
-- lg
On Sep 11, 2014, at 2:19 PM, Stastny, Bret <[email protected]> wrote:
> This is your problem:
>
> Total size of all images referenced : 1.7 GB
> Read from disk : 10.3 GB
>
> You basically read the total sum of your texture size 5X during your run.
>
> If you can set your texture cache to >= 1.7GB you will see a big speed up.
> Making it any larger than the default 250MB is going to help you. Depending
> on your texture working set tweaking this can make a big difference and you
> should keep an eye on it as you continue to develop or add more concurrent
> textures that need to be accessed. Proper mip mapping will also help reduce
> your memory needs for textures. We typically allocate up to half the system
> memory to our texture cache size, because we have the memory to spare.
>
>
> We routinely run with tiled and mipped exr files without any problem, we use
> our own compression on them.
>
> -bret
>
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
