Re: [Oiio-dev] OIIO storage and performance

Ha! No, I meant that a 2x improvement between bad texture format and an optimal texture format is less surprising than a 5.5x improvement. It's still a significant and welcome improvement, but it's not so outrageous an improvement that it arouses suspicions. On Wed, Sep 14, 2016 at 6:20 PM, Larry

Re: [Oiio-dev] OIIO storage and performance

Depends on the overall organization of the logic, I guess. OpenEXR is an easier case because there's really only one place where you use the instruction: inside a function that converts a whole scanline or tile from half to float or vice versa. So a loop of a whole lot of conversions can be ins

Re: [Oiio-dev] OIIO storage and performance

> But you MUST run that version of TextureSystem only on machines that > support those hardware instructions! > How feasible is it to do a runtime cpuid check and only take the f16c paths on supported cpus? Then you can have one binary to rule them all. Thats how we handle f16c (and avx) in open

Re: [Oiio-dev] OIIO storage and performance

Ah, too bad. Yeah, we also don't rely on that quite yet. Well, if you have a newer machine somewhere that does support it (anything newer than the machine you cited is likely to have it), give it a try with and without to see if makes a difference. > On Sep 14, 2016, at 11:13 AM, Dan Kripac w

Re: [Oiio-dev] OIIO storage and performance

Hey Larry, I've been compiling OIIO 1.7.3dev with USE_SIMD=sse4.2 but not the f16c. Doing cat /proc/cpuinfo on my (slightly old) machine shows these flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb r

Re: [Oiio-dev] OIIO storage and performance

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 c

Re: [Oiio-dev] OIIO storage and performance

Note to self: 2x improvement is "acceptably but not outrageously faster." Must recalibrate reactions to Søren's compliments. > On Sep 14, 2016, at 3:02 AM, Søren Ragsdale wrote: > > > > On Mon, Sep 12, 2016 at 7:52 PM, Larry Gritz > wrote: > Note also that this r

Re: [Oiio-dev] OIIO storage and performance

On Mon, Sep 12, 2016 at 7:52 PM, Larry Gritz 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

Re: [Oiio-dev] OIIO storage and performance

Well, there only seem to be 3 variables at play (apparently), so we can vary each of them individually and see what happens: 1. Tile size (64x64 vs 64x32) 2. Separate vs contiguous planarconfig 3. Compression type (lzw vs zip) Out of curiosity, is there any difference in file size on disk? Note

Re: [Oiio-dev] OIIO storage and performance

Thanks for helping me look into this. Here's the output typical of the three kinds of texture files that I'm comparing. $ oiiotool -v -info */lodDefault.1001.* "OIIO optimized TIFF" (00:21:46) Reading tiff/lodDefault.1001.tif tiff/lodDefault.1001.tif : 4096 x 4096, 4 channel, half tiff MIP-

Re: [Oiio-dev] OIIO storage and performance

I neglected to say: This is certainly odd. I do expect OIIO's default settings to outperform the ones that kick in when we try to make textures that are compatible with prman, but not by a large factor. Something weird is happening here, and it will be instructive to figure it out. > On Sep 12

Re: [Oiio-dev] OIIO storage and performance

You're missing a key item from the 'txinfo' -- I can't tell what data type it is or if it's MIPmapped. Try 'oiiotool -v -info prman.tif oiio.tif', and show the entire output for both files. One thing that comes to mind is the tile size -- OIIO uses 64x64, that seemed optimal when I did extensi