This article explains how Mari works against each hardware component and what it uses them for.
GPU (Speed & #cores) :
The GPU is used for rendering and also for baking out the result to textures. Therefore, a faster GPU can render a heavier scene at a better frame rate and shorten the time to wait for baking to textures (i.e. “Flatten Layers”, “Merge Layers”, “Convert Procedural to Paintable”)
GPU (Memory) :
The bigger the GPU's memory, the easier it is to paint more details in general. The two biggest occupiers of GPU memory in Mari are:
- Paint Buffer - If the GPU's memory is big, one can set the paint buffer's resolution higher (4k or potentially even 8k) and/or set the bit depth of the paint buffer higher (16 or 32 bits instead of 8 bit).
A higher resolution paint buffer allows for more details without having to repeatedly zoom, paint & bake. Higher bit depth of the paint buffer prevents stepping, especially for displacement maps.
- Virtual Texture Atlas - Mari uses virtual texturing to fit a large amount of texture data. However, there of course is a limit. If Mari cannot fit all data, Mari will start using lower resolution mipmaps.
If the GPU's memory is big, one can set the virtual texture size big so that Mari can render a really heavy scene (Lots of layers, lots of UDIMs and/or lots of fragmented UV bits).
In general, a moderate quad core processor would be good enough, but certain non-GPU operations will benefit from more cores or faster CPU. The examples of non-GPU operations in Mari are:
- Ambient occlusion calculation
- Whole patch bleed
- Tile level bleed after baking
- Changing bit depth of a channel
- Changing resolutions of textures
4GB is OK, but 8GB would be better for more stable operation, especially if running other 3D apps. If one wants to work with a heavy scene, the more RAM the better.
Ultimately, all data in Mari is cached out to disk, so even if RAM is small, Mari runs OK. There will be more disk read happening. RAM 's primary usage in MARI are:
- General applications RAM usage (UI, application logic etc)
- Texture data loaded into RAM from a disk will stay in RAM, but will be removed from RAM in LRU (Least recently used) manner.
An SSD is highly recommended. Mari's long taking operations are often bottle-necked by disk writing. An SSD will greatly help in reducing the time for writing to disk. Regardless if some data is processed by CPU or GPU, the resulting data is ultimately written to a disk.
If a project is light (E.g. A few UDIMs with up to 4k textures), an SSD may not make a big difference though.
Scratch space : We have not experimented with scratch space. I estimate that it does not matter so much for Mari. Mari does its own data management of keeping recent data in RAM in LRU basis while all data is written to a disk anyway.
Keywords: Mari, Hardware, recommendations, HDD, memory, CPU, GPU, resources