In all those cases, Mistika will 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 GPU depending on the render codec.
Logically, the total 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 CPUs, and because it does not make sense for the CPUs to decode more frames per second than the GPU can ingest.
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 28 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 too many cores.
Regarding the GPU that is normally the most important component (more than the CPUS), so chose the fastest one available. However this article is about CPU optimizations, so we will not go into more details.
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 represenative timeline with optical flow activated). We can distinguish 2 main cases.
1 - If you see that either the CPU or the GPU usage is well over 90% for most of the time, then a hardware upgrade for that particular component would be required to . Maybe you could still improve your Workflow with some techniques like working with proxies as much as possible and only doing the final render at full resolution, but rest assured that you are already squeezing your current hardware to the limits.
2 - But if don't see very high activity in none of those (GPU and CPUs), then it may be that Mistika is not using the CPUs as efficiently as possible, so they are not decoding and feeding enough frames per second to the GPU as they could do. 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 this:
Under you user home folder, find this file: SGO AppData/VR/localPreferences.xml
Make a backup of it, then edit the file in a text editor and change these parameters:
ioThreads: This is the number of 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 specially because many 3rd party codec libraries will also split their own threads without Mistika being able to control this). So it may be worth it to try to find optimal values by trying manually and comparing.
In principle, the most aggresive value that you should try would be to put the number of total CPU threads of your CPUs (you can get this value from the Task Manager), but in general we don't recommend to go over 24. If the value is too high it will reduce the performance, waste RAM, and ultimately destabilize the system. Also please note that for rendering processes you will need to dedicate some threads to that part...
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 for the camera decoding).
We do not not recommend to change other values, even if their names may sound related changing them is not expected to help performance at all (quite the opposite). And in many cases they are there just because the configuration template is shared with other Mistika applications.