Both Mistika playback and render try to use the GPU and CPUs at the same time to aggregate the performance of both components, by doing this:
- The CPUs will be pre-decoding camera codecs to extract the next frames in advance. This can be very intensive processing if there are many cameras (4 or more) or if they use high resolution.
- Meanwhile, the GPU will be doing the stitching and optical flow of the previous frames.
- If we are in a render process, at the same time Mistika will also be encoding the rendered frames into the selected codec. This can require additional resources either from the CPUs or the GPU depending on the render codec.
The total render time will depend on the speed of the slowest part of the process, not the fastest one. Because logically the GPU can not stitch more frames per second that it gets from the CPU decoders, and because it does not make sense for the CPUs to decode more frames per second than the GPU can process. And the same happens for the encoding process at render time.
So even if the CPUs seem to do a secondary job it is crucial that they feed enough frames per second to the GPU as to keep it busy and efficient.
Nowadays the most typical VR cameras use h264/h265 codecs. This article is mainly to optimize the CPU usage for those cases, although it can also help when the render formats are CPU intensive ( like it is the case with exr compressed, Prores, and jpg)
At hardware purchase time, select the CPUs with the highest value of this formula:
Number of CPUS x Number of CPU cores x Base clock speed
It also depends on other factors like generation, AMD or Intel, etc. But those are secondary aspects and this formula has demonstrated to be a good reference over the last 8 years, even when comparing different generations. The facts is that CPU brands use a lot of fancy names for additional features, but in general they are secondary aspects when not irrelevant.
However, in general we don't recommend to have more than 24 to 32 cores or so, as for most image formats the number of cores does not increase performance linearly. In case of doubt get the CPUs with the fastest clock speeds, better than having some extra cores.
Regarding the GPU that is normally the most important component (more than the CPUS), so choose the fastest one available. However this article is mainly about optimizations for CPU related settings (mainly because there is not too much that you can do to improve the other components apart from upgrading the hardware itself), so the rest of the article is dedicated to CPU settings.
CPU Software optimizations:
Once we go into software optimizations, first thing is to study the situation in the Task Manager or Activity Monitor during playbacks and render (using a representative timeline with optical flow activated). We can distinguish two main cases.
1 - If you see that either the CPU or the GPU usage is around 75% or more for most of the time, then a hardware upgrade for that particular component would be required to get more speed. Maybe you could still improve your Workflow with some techniques like working at lower resolution as much as possible and only doing the final adjustments and final render at full resolution, but you can rest assured that you are already squeezing your current hardware close to the limits.
The reasons why we say 75% and not an even higher value are:
- If the CPUs have "hyperthreading" activated (recommended), then you will rarely get 100% usage of all CPU threads (Hyperthreading creates extra "virtual threads" that are not independent but need to share CPU resources), so it is rare to get more than 75% total usage or so.
Please note that having double number of CPU threads, having 75% of them fully busy is way faster than getting 100% speed with hyperthreading deactivated (half number of CPU threads). So if you get 75% or more then you are probably getting most of the speed that is possible.
- The GPU activity is more common to be seen over 90% usage (specially for optical flow processing), but having a system around 75% usage for both the CPU and the GPU will just mean that it is very well balanced for the particular job and there is no clear bottleneck, so there is not much to say, just congratulations for choosing the optimal hardware combination for your work.
2 - But if you don't see very high activity in none of those (GPU and neither CPUs), then it sounds that Mistika is not using the CPUs as efficiently as possible, so that they are not decoding and feeding enough frames per second to the GPU as they could do (which will make the GPU also idle most of the time). This is not always true because other components maybe involved (not enough RAM, slow disk access, usage of GPU "shared" memory....), but if you don't see any evident cause it may be worth to try manually adjusting these settings. Now going into the matter:
Under you user home folder, find this file: SGO AppData/VR/localPreferences.xml
Make a backup of it just in case, then edit the file in a text editor and change these parameters:
ioThreads: This is the number of CPU threads dedicated to decode camera source frames in parallel. The default is 0 (zero), which means that Mistika will try to guess good values for your system. However it can be pretty difficult for Mistika to predict a good value in advance, and sometimes Mistika can bee too conservative in order to prevent destabilizing the system (big values may use a lot of RAM and be inefficient, specially because many 3rd party codec libraries will also split their own threads without Mistika being able to control this aspect, and because it needs to reserve some threads for rendering and the OS). So it may be worth it to try to find optimal values by trying manually and comparing.
In theory the most aggressive value that you could try would be to put the number of total CPU threads of your CPUs (you can get this value from the Task Manager/Activity Monitor), but in general we don't recommend to go over over 2/3 the total number of CPU threads, and no more than 24 as an upper limit. If this value is too high it will reduce the performance, waste RAM, and ultimately destabilize the system. Please note that rendering and codec libraries will need to split some threads on their own as said, and also the operating system...
encodeThreads: This is basically the same concept but in this case for encoding the render format. 0 means autoconfiguration, which will use up to half the threads of the system or so, thus letting the others available for decoding the cameras. But if the render format is very complex (if playbacks are fast but render proceses are much slower) then you could force a high value as in the previous case, (but remember to let enough threads available for the camera decoding).
On systems with Hyperthreading activated, neither ioThreads and encodeThreads should be higher than two thirds of the total number of CPU threads. For example if your system has 16 core / 32 threads (Hyperthreading) then the maximum recommended value would be 32 * (2/3) = 21. Higher values will decrease Mistika speed due to inefficient usage of the system resources.
NOTE: We do not not recommend to change any other values in this file, even if their names may sound related to render settings changing them is not expected to help performance at all (quite the opposite). In the best case they are there just because the configuration template is shared with other Mistika applications and they will not affect Mistika VR at all, and in the worst case they can make the application unstable.
Finally, when using complex codecs like R3D, EXR, or requiring control of camera raw extraction it is highly recommended to finish the job with Mistika Boutique and render with it rather than using Mistika VR for everything. Mistika Boutique is a more complex product to learn, but it also provides more powerful functionality (the Mistika VR toolset is a small subset of Mistika Boutique functionality) and provides additional optimizations.