Hi, I’m in the middle of integrating OIIO’s TextureSys into a path tracer. Previously, textures were just loaded into memory in in full, and lookups would always happen at the full resolution, without mip maps. When replacing that with TextureSys, I’m noticing a significant performance drop, up to the point where texture lookups (sample_bilinear() for example, sample_bicubic() even more) occupy 30% or more of the render time. This is with good cache hit rates, the cache size exceeds the size of all textures and the OIIO stats report a cache miss rate of < 0.01% (in addition, I tried hardcoding dsdx/dsdy/dtdx/dtdy to 0.01, just to be sure).
I did expect some performance drop compared to the previous naive strategy, but this is a bit steeper than I expected. I am wondering if I am doing something wrong on my side and if there are some best practises on how to integrate OIIO into a path tracer. (I had it running in a REYES renderer years ago and don’t remember it being that slow.) I am creating one TextureSys instance per CPU thread, with a shared ImageCache - are separate caches per thread any better? I cache perthread data and do lookups using TextureHandle, not texture name. Do people generally use smartbicubic for path tracing or do you not see enough of a difference and stay with bilinear (as pbrt does)? For any diffuse/sss/smooth glossy/etc bounces, I use MipModeNoMIP/InterpClosest. I am observing this on macOS, Windows and Ubuntu, OIIO built with whatever compiler flags CMake picks for a Release build. Is it worth it forcing more aggressive optimisation (-O3 -lto -ffast-math…)? Thanks, Stefan _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
