testtex --threadtimes <n> computes threading benchmarks of the texture system.
testtex --threadtimes <n> computes threading benchmarks of the texture system.

The argument n selects among one of several "workload profiles" that
simulate different access patterns (e.g., all threads access the same
pixel, all threads access the same file but at different coordinates,
different threads access different files, etc.).  Then it runs a whole
bunch of texture queries with differing numbers of threads and prints
a report.

The idea is to have an objective way to measure thread performance and
efficiency, allow us to zero in on exactly where the threading
bottlenecks are, and know exactly how much any proposed fixes improve
various situations.

Example usage:
    # first, make lots of copies of a texture file
    mkdir tmp ; chdir tmp
    for i in 0 1 2 3 4 5 6 7 8 9 ; do for j in 0 1 2 3 4 5 6 7 8 9 ; do ln -s ../grid.tx grid$i$j.tx ; done ; done
    cd ..
    # run benchmark
    testtex --nodedup --threads 12 --wedge --threadtimes 7 tmp/grid*.tx

Example output:
    Workload: Coherent access, many files, partially overlapping texture sets
    texture cache size = 256 MB
    hw threads = 12
    times are best of 3 trials

    threads  time (s) efficiency
    -------- -------- ----------
     1          4.32  100.0%    range 0.01  (2000000 iters/thread)
     2          4.30  100.5%    range 0.40  (2000000 iters/thread)
     4          4.88   88.5%    range 0.10  (2000000 iters/thread)
     6          7.81   55.3%    range 0.03  (2000000 iters/thread)
     8         13.36   32.3%    range 0.38  (2000000 iters/thread)
    10         19.89   21.7%    range 0.01  (2000000 iters/thread)
    12         26.06   16.6%    range 0.12  (2000000 iters/thread)

Now, keep in mind that this is really stressing just the texture system;
we are not seeing such bad performance degredation in actual renders.
But still, if we can improve efficiency of highly threaded "texture
access only" benchmarks, surely that will bring improvement to a real
render (of which texture is only part) as well.

But yowee, I'm not happy with our texture performance when there are
more than 4 threads.  Being able to quantify this and keep my feet to
the fire is precisely the reason for this patch.

bdeluca/oiio,lgritz/oiio,YangYangTL/oiio,lgritz/oiio,micler/oiio,cwilling/oiio,scott-wilson/oiio,mcanthony/oiio,sambler/oiio,mcanthony/oiio,YangYangTL/oiio,sambler/oiio,scott-wilson/oiio,scott-wilson/oiio,bdeluca/oiio,OpenImageIO/oiio,OpenImageIO/oiio,OpenImageIO/oiio,micler/oiio,YangYangTL/oiio,mcanthony/oiio,scott-wilson/oiio,YangYangTL/oiio,cwilling/oiio,bdeluca/oiio,micler/oiio,sambler/oiio,mcanthony/oiio,micler/oiio,bdeluca/oiio,OpenImageIO/oiio,lgritz/oiio,cwilling/oiio,lgritz/oiio,sambler/oiio,cwilling/oiio