This article explains how Mari works with each of a computer's hardware components and what it uses them for.
GPU - Speed and number of cores
The GPU is mostly used for viewport rendering and for baking textures. Therefore, a faster GPU can render a heavier scene at a better frame rate and shorten waiting time when baking textures. This affects actions such as “Flatten Layers”, “Bake to Paint Node”, “Convert Procedural to Paintable”, or Baking a Bake Point node.
GPU - Memory
The bigger the GPU's VRAM, the easier it is to paint in general. The two biggest occupiers of GPU memory in Mari are:
- Paint Buffer - With more GPU memory, the user can set the Buffer Size and Color Depth settings of the Paint Buffer higher, such as setting it to 8k and 32 bit.
With a higher resolution Paint Buffer, the user can paint more details without having to repeatedly zoom in closer to the asset. Additionally, higher bit depth prevents stepping when a smooth transition between values is essential, such as in displacement maps.
- Virtual Texture Atlas - Mari uses virtual texturing to render large amounts of texture data in the viewport. However, there is a limit. If Mari cannot process all data in a timely manner, it will start using lower-resolution mipmaps in the Viewport. This won't affect the actual textures that get exported out of Mari, but it does affect the quality they're displayed at in Mari's viewport.
With more GPU memory, the user can increase the Virtual Texture size preferences so that Mari can render a really heavy scene, such as one with many layers, UDIMs or UV Islands.
NOTE: Information about how to calculate the GPU memory required for your Project can be found in the following article: Q100313: Calculating your GPU memory usage for Virtual Textures in Mari
In general, a moderate quad-core processor is sufficient, but certain non-GPU operations benefit from more cores or a faster CPU. A few examples of non-GPU operations in Mari are:
- Calculating ambient occlusion
- Whole Patch Bleed
- Tile level bleed after baking
- Changing the bit depth of a channel
- Changing the resolution of textures
4GB is adequate, but 16GB or higher is ideal for more stable operation, especially if running other 3D apps at the same time as Mari. If the user wants to work on a heavy scene, more RAM is recommended.
Ultimately, all data in Mari is cached out to disk, so even if RAM is small, Mari should run okay. RAM's primary usage in Mari are:
- General processes that most applications use RAM for, such as application logic or UI.
- Texture data loaded into RAM from disk will stay in RAM, but will be removed from RAM in a LRU (Least recently used) manner.
A spacious SSD is highly recommended, especially for the Project Location. Mari's lengthy operations are often bottle-necked by disk writing, and an SSD can greatly reduce the time it takes to write data to disk. Regardless of whether a piece of data is processed by the CPU or the GPU, it is ultimately written to a disk.
However, if a Project is light, such as 5 UDIMs with 4k textures, an SSD may not make a significant impact, this is most noticeable in heavy Projects and any other heavy export operations.
Note: Project Location can be changed by selecting Edit > Preferences > Data > Project > Project Location.
Note: We have not experimented with scratch space, but we estimate that it wouldn't impact performance, as Mari does its own data management of recent data in RAM on a LRU basis, and all data is written to a disk anyway.
Mari's official system requirements can be found here: Mari tech specs
If you are still experiencing any issues, please create a support ticket and provide us with the information requested in this article: Q100090: Reporting a Mari issue
For more information on how to open a support request, please refer to this article: Q100064: How to raise a support ticket
We're sorry to hear thatPlease tell us why