OK, two notes: First, as relieved as I am that the default OIIO texture parameters (presumably the contig planarconfig and the larger tile size?) give much better performance, I'm still a little alarmed that texture I/O is a big enough part of your render in the first place. I'd love to see a clip of the full OIIO IC stats for the render. I wonder if you are accessing texture in a very incoherent way that's thrashing the cache. There may be other things you can change that will drastically reduce the remaining I/O time.
Second, Soren, do you know what USE_SIMD=... settings you are using when building OIIO, and what the minimum hardware capabilities are of your machines? In particular, do you know whether all your hardware supports the "f16c" capability? Newer chips have hardware instructions that can do fast conversion from half to float and back. If so, you should tell OIIO to build with this (make USE_SIMD="sse4.2,f16c"), it might speed up the texture math if you are using a lot of 'half' textures. But you MUST run that version of TextureSystem only on machines that support those hardware instructions! (This will help if the remaining time includes a lot of texture math; if it's really the I/O itself that's the main culprit, it will make less of a difference.) On Linux, 'cat /proc/cpuinfo' will show you all the hardware capability bits, like which SSE/AVX levels you're at and whether f16c and fma are present. > On Sep 14, 2016, at 3:02 AM, Søren Ragsdale <sor...@gmail.com> wrote: > > > > On Mon, Sep 12, 2016 at 7:52 PM, Larry Gritz <l...@larrygritz.com > <mailto:l...@larrygritz.com>> wrote: > Note also that this reveals that the "genuine PRMan texture" appears to be > saving uint16... I'm not sure if that means it really is converting to > uint16, or if it's faking it by storing half in a uint16 container (which > would surely not behave properly for an OIIO-based texture system). > > Well I feel silly. I've overlooked a major difference. Maketx refuses to put > float16 data into TIFFs. The prman texture contains int16 data. > > fake_prman/lodDefault.1001.tex : 4096 x 4096, 3 channel, half tiff (+mipmap) > real_prman/lodDefault.1001.tex : 4096 x 4096, 3 channel, int16 tiff (+mipmap) > > I've regenerated the textures so that they're both equivalent: > > fake_prman/lodDefault.1176.tex : 4096 x 4096, 3 channel, half openexr > (+mipmap) > real_prman/lodDefault.1176.tex : 4096 x 4096, 3 channel, half openexr > (+mipmap) > > ... and the render times are close enough for me: > > fake_prman 00:45:16 > real_prman 00:42:15 > > ... as opposed to the optimized OIIO EXR textures, which are acceptably but > not outrageously faster: > > exr/lodDefault.1176.exr : 4096 x 4096, 3 channel, half openexr > > exr 00:21:14 > > Mystery solved? > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz l...@larrygritz.com
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
