Memory-Mapped Textures

mental ray supports memory mapping of textures on UNIX and NT. Memory mapping means that the texture is not loaded into memory, but is accessed directly from disk when a shader accesses it. There is no special keyword or option for this; if a texture is memory-mappable, mental ray will recognize it and memory-map it automatically. Only the map image file format (standard extension .map, but mappable files are recognized even if they have an extension other than .map) can be mapped. See the Output Shaders chapter for a list of supported file formats.

Note that memory mapping is based on the concept that the image data on disk does not require decoding or data type conversion, but is available in the exact format that mental ray uses internally during rendering. Normally mental ray will attempt to auto-convert image data formats; for example if a color image file is given in a scalar texture construct, mental ray will silently convert the color pixels to scalars as the texture is read in. Most data types are auto-converted to most other data types. This does not work for memory-mapped textures because it would defeat the purpose. This also applies to the byte order.

Memory mapping requires several preparation steps:

The texture must be converted to .map format using a utility like mental images' imf_copy. The scene file must be changed to reference this texture. Note that mental ray recognizes .map textures even if they have an extension other than .map; this can be exploited by continuing to use the old file name with the "wrong" extension, to avoid having to change the scene file. When using imf_copy, the -p option is highly recommended to create a texture pyramid in the file.
Memory-mapped textures are automatically considered local by mental ray 2.1, as if the local keyword had been used in the scene file. This means that if the scene is rendered on multiple hosts, each will try to access the given path instead of transferring the texture across the network, which would defeat memory mapping. The given path must be valid on every host participating in the render. mental ray 3.x also supports nonlocal mapped textures, so that it is mapped on the master but fetched across the network by slaves if the local keyword is not supplied, which simplifies scene distribution but may incur unacceptable network overheads.
The texture should not be on an NFS-mounted file system (one that is imported across the network from another host). Although this simplifies the requirement that the texture must exist on all hosts, the necessary network transfers reduce the effectiveness and can easily make memory-mapping slower than regular textures.
Memory-mapping works best if there are extremely large textures containing many tens of megabytes that are sampled infrequently because then most of the large texture file is never loaded into memory.
A memory-mapped file texture must be created on a host with the same byte order as the host where it will be used. mental ray will not memory-map textures with an incompatible byte order, and read the whole texture into memory and convert it instead. This is not efficient and should be avoided.

If the textures and the scene are so large that they do not fit into physical memory, loading a texture is equivalent to loading the file into memory, decompressing it, and copying it out to swap. (The swap is a disk partition that acts as a low-speed extension of the physical memory that exists as RAM chips in the computer.) From then on, accessing a texture means accessing the swap. Memory mapping eliminates the read-decompress-write step and accesses the texture from the file system instead of from swap. This has the side effect that less swap space is needed. If the texture and scene are not large and fit into memory, and if the texture is accessed frequently, memory-mapped textures are slightly slower than regular textures because the swap would not have been used, but for textures that are larger than perhaps a hundred kilobytes (uncompressed), memory mapping is a much more efficient way of loading textures.

This is especially important for mental ray 3.x, which manages memory as a cache. Non-memory mapped textures are a big drain on the cache because they tend to take up large portions of cache memory. mental ray 3.x has a separate virtual cache manager that loads and unloads memory-mapped textures efficiently without blocking the regular cache.