On Sep 11, 2014, at 12:36 PM, Simon Smith <[email protected]> wrote:
> Thanks for the information - once I got the stats out on shutdown it quickly
> came apparent that it was not utilising *any* of the mipmaps because I was
> using 0 for all the derivatives. I’d like to clarify what these should be
> though.
Yep, that would do it alright. If the total texture referenced is larger than
your in-memory cache, and you're not using MIP-mapping, and your lookup access
pattern is sufficiently incoherent, you really can't help but thrash, because
so many texture references will have a high probability of not being in cache.
Proper derivatives, so that MIPmaps can be allowed to work, is the main
ingredient to fixing this. You may also want to raise the cache size from the
default 256MB. It doesn't need to be anywhere near as much as the total
texture you may use -- there is usually a tipping point (the "working set" may
be much smaller than the total you will touch during the render) where
performance suddenly changes. This may differ based on the needs of your
facility and what kinds of scenes you have. At SPI, I think our default is 500
MB, and we don't hesitate to raise it to 1 GB for big shows, and with that we
get excellent performance for scenes that reference in the range of 0.5-1.0 TB
of texture spread across 1,000-10,000 texture files.
> When I calculate the derivatives I’m using a value of the original source
> image size divided by the final rendered image size (this probably slightly
> oversampled as the source image will not cover the final image completely,
> but it’s a good approximation).
>
> For the s derivatives I use this delta for the dsdx, and 0 for dsdy, and for
> the t derivatives I’m using a similarly calculated value for dtdy, and 0 for
> dtdx. I’m using 0 because I don’t think there is a change in that axis across
> the sample, but I’m not sure that is correct - could someone please clarify
> how these values should be correctly calculated.
This sounds correct if your texture is aligned to, and fills, the output window.
Basically, you want your app to understand how the texture coordinates change
from one pixel to the next, that's the meaning of dsdx, dtdx, dsdy, dtdy.
Good old calculus -- if you know the formula that relates texture coordinates
to output display coordinates, you can just differentiate it.
> Once I changed the derivatives, the difference was dramatic, and seems to be
> traced down to the mipmap usage (which makes complete sense really).
> I should note that I found another instance of using the incorrect
> derivatives after taking this stat grab below which resulted in the largest
> mipmaps never being used (they were pushed down to the 2nd and 3rd mipmaps),
> the peak memory usage dropping to less than 200Mb, and main cache misses down
> to 0.001% - all improving performance of course.
Yes, that's what I want to see!
The stats can be really helpful in tracking these things down.
> In terms of how we access the textures, we process single output pixels at a
> time and pull in texture values from as many images as are overlaying on that
> point. So whilst there is some continuity in the accessing the pixels in any
> one texture (by the nature of the fact that I am just compositing the images
> onto a destination through a re-projection) this process runs over multiple
> threads so can potentially be reading out of different areas of the same
> texture on different threads, but I guess this is where tiling come into it
> though!
Yeah, that's all fine, and exactly what the system is designed for. I just
wanted to make sure you weren't doing something pathological, like truly
selecting nearly random texture coordinates from one lookup to the next.
> When we allow for loading EXR files (or an other non-tx files) I’m thinking
> we should make sure that we have the mipmap and tile attributes set so that
> they are generated for us by the texture system. Would that be correct? If
> so, when is the tiling and mipmapping done - is it on loading the image, or
> does it do it just as and when needed in some special way? I’m just trying to
> get a handle on when the hit for access these non-tx’d files will come in.
Best is to create the tiled MIPmaps (with maketx) before you start. This is
most efficient, and of course allows the work of making the MIPmap to be
amortized over all the fames and machines that will need that texture.
OIIO's TextureSystem has facilities to deal with untiled and/or un-MIP-mapped
images (controlled by the "automip" and "autotile" attributes), but no matter
how you slice it, performance or memory or both really suffers. The transparent
handling of untiled/unmipped images is only intended to work well for very
simple scenes with just a few images whose total will fit in cache anyway,
under the assumption that simple scenes go along with naive users who probably
won't know how or want to maketx their images.
Now, to clear up a couple details:
* There is no such thing as a ".tx" format.
* The TextureSystem will accept *ANY* image file format that OIIO will read.
Though performance is immeasurably better if the file is tiled and MIPmapped,
and only a few image file formats support these features.
* All that maketx is doing is converting its input to tiled, MIPmapped, and
setting some other miscellaneous metadata in the resulting texture file. It
outputs TIFF by default (some people name those files "*.tx", but that's just a
convention), but if you call the output file "*.exr", it will write it as an
EXR file, which is another excellent format that supports MIPmapping and tiles.
There is, unfortunately, no single best output format for maketx. TIFF can't
hold "half" (16 bit float) files. (Actually, it's been brought to my attention
that there is a not-widely-known extension that allows this, but I haven't
rigged it up yet for maketx.) Also, TIFF's handling of arbitrary metadata and
nonzero-offset display windows isn't as flexible as OpenEXR. On the other hand,
OpenEXR can't output texture in uint8 or uint16 formats, which is what a lot of
textures are. So it's a tradeoff, but OIIO really doesn't care which you use.
-- lg
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
