Using oiiotool and maketx to create a mipmap debug texture

To visualize the different mipmap levels, you can create a custom tx file with different textures for each mipmap level. It’s pretty easy to do with maketx. (or you can download this one)

First, to create the different mipmap levels, I use oiiotool (I use the one shipped with HtoA).

oiiotool --pattern checker:width=32:height=32:color1=1,0,1 8192x8192 3 -o 8192.tif
oiiotool --pattern checker:width=32:height=32:color1=1,0,1 8192x8192 3 -o 8192.tif
oiiotool --pattern checker:width=32:height=32:color1=1,0,0 4096x4096 3 -o 4096.tif
oiiotool --pattern checker:width=32:height=32:color1=1,.25,0 2048x2048 3 -o 2048.tif
oiiotool --pattern checker:width=32:height=32:color1=0,0,1 1024x1024 3 -o 1024.tif
oiiotool --pattern constant:color=1,1,0 512x512 3 -o 512.tif
oiiotool --pattern constant:color=0,1,1 256x256 3 -o 256.tif
oiiotool --pattern constant:color=.5,0,0 128x128 3 -o 128.tif
oiiotool --pattern constant:color=.5,.5,0 64x64 3 -o 64.tif
oiiotool --pattern constant:color=0,1,0 32x32 3 -o 32.tif
oiiotool --pattern constant:color=.5,0,.5 16x16 3 -o 16.tif
oiiotool --pattern constant:color=.82,.41,.12 8x8 3 -o 8.tif
oiiotool --pattern constant:color=0,.5,.5 4x4 3 -o 4.tif
oiiotool --pattern constant:color=0,.75,1 2x2 3 -o 2.tif
oiiotool --pattern constant:color=.5,.5,.5 1x1 3 -o 1.tif

You can’t use constant colors for all the levels, because OIIO will optimize your texture into a constant color and there won’t be any texture access.

Then I use the -mipimage flag to combine all the mipmap levels into a tx file:

maketx 8192.tif ^
-mipimage 4096.tif ^
-mipimage 2048.tif ^
-mipimage 1024.tif ^
-mipimage 512.tif ^
-mipimage 256.tif ^
-mipimage 128.tif ^
-mipimage 64.tif ^
-mipimage 32.tif ^
-mipimage 16.tif ^
-mipimage 8.tif ^
-mipimage 4.tif ^
-mipimage 2.tif ^
-mipimage 1.tif ^
-format exr -d half -o debug.tx

Here’s a couple of examples of using mip-map bias with the debug tx file.

Mip-map Bias = -1 (read a higher resolution mipmap)


Mip-map Bias = 2 (read two-levels lower resolution mipmap)



The case of the 15% rendering utilization

Or, “Understanding the Arnold log, part 23”

In this case, a client had very low (15%) CPU usage for a render. We got the Arnold log, and here’s the interesting part:

00:01:44  856MB   | OpenImageIO ImageCache statistics (0000000025850F20) ver 1.5.24
00:01:44  856MB   |   Images : 3 unique
00:01:44  856MB   |     ImageInputs : 299 created, 2 current, 3 peak
00:01:44  856MB   |     Total size of all images referenced : 192.4 MB
00:01:44  856MB   |     Read from disk : 12.0 GB
00:01:44  856MB   |     File I/O time : 45m 41.5s (48.1s average per thread)
00:01:44  856MB   |     File open time only : 0.0s
00:01:44  856MB   |   Tiles: 711523 created, 559 current, 640 peak
00:01:44  856MB   |     total tile requests : 249379431
00:01:44  856MB   |     micro-cache misses : 3353694 (1.34482%)
00:01:44  856MB   |     main cache misses : 711523 (0.285317%)
00:01:44  856MB   |     Peak cache memory : 10.0 MB
00:01:44  856MB   |   1 not tiled, 1 not MIP-mapped
00:01:44  856MB   | -----------------------------------------------------------------------------------
00:01:44  856MB   | performance warnings:
00:01:44  856MB   | Rendering utilization was only 15%. Your render may be bound by a single threaded process or I/O.
00:01:44  856MB   | -----------------------------------------------------------------------------------
  • File I/O time seems a bit high for three textures and a render that took less than 2 minutes
  • main cache* misses is pretty high. Normally you expect something less than 0.01%.

    0.285% means that texture tiles are loaded from disk (instead of from the in-memory texture cache) once out of every 350 texture lookups. That’s a little high.

    * The main cache is the cache of 64×64 texture tiles loaded from disk into the texture cache.

  • Peak cache memory is 10.0 MB !!! That explains the main cache misses: the texture cache is really, really small.

Other clues to the too-small texture cache size:

  • Read from disk is 12 GB but the total size of all images referenced is just 192.4 MB, and the peak cache memory was just 10.0 MB
    So the same texture data is constantly being unloaded from the cache and reloaded from disk.

The solution? Increase the size of the texture cache. The current default is 2048, which should be good in most cases.