Performance Problems: Difference between revisions

From MXWendler Wiki
Jump to navigation Jump to search
Behrooz (talk | contribs)
No edit summary
Behrooz (talk | contribs)
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 51: Line 51:
*extreme large output sizes.  
*extreme large output sizes.  


{{#mpdftags: pagebreak}}
Am I GPU limited? <br>
Am I GPU limited? <br>


Line 59: Line 60:
*A solution may be to rework your visual setup.  
*A solution may be to rework your visual setup.  
:Use only the resolutions you need, and keep resolutions below certain limits, especially Power-Of-Two limits.  
:Use only the resolutions you need, and keep resolutions below certain limits, especially Power-Of-Two limits.  
::An image with a width of 1024 will be placed in a 1024 texture  
::An image with a width of 1024 will be placed in a 1024 texture.
::An image with a width of 1025 will be placed in a 2048 texture,
::An image with a width of 1025 will be placed in a 2048 texture.
*( at least ) doubling the GPU RAM usage  
*Try (at least) doubling the GPU RAM usage.
*Under NVidia, for optimal performance, disable the following:
*Under NVidia, for optimal performance, disable the following:
:Anisotropic filtering  
::Anisotropic filtering  
:Antialiasing  
::Antialiasing  
:Texture filtering  
::Texture filtering  
 
*Use 'Single GPU Performance Mode' in combination with a device to split the video output.  
* Use 'Single GPU Performance Mode' in combination with a Matrox to split the video output.  
*Be sure your Keystone setup ( in fact, this is geometry ) is not too complex for your graphics board.
 
* Be sure your keystone setup ( in fact, this is geometry ) is not too complex for your graphics board.  


=== System Busses ===
=== System Busses ===


* Video data has to be carried from the disk to the cpu to the graphics card. At each stage, the video is decompressed, and the data stream will take more bandwidth.  
Video data has to be carried from the disk to the cpu to the graphics card. At each stage, the video is decompressed, and the data stream will take more bandwidth. <br>
** - be sure that your disk bus is as fast as the disk. There is no point in connecting a fast RAID to USB 1.1  
*Be sure that your disk bus is as fast as the disk itself. There is no point in connecting a fast RAID to USB 1.1.
** - Have fast memory and a fast mainboard. Mac Pro is a reference design in that area.
*Always pair fast parts together, e.g use a fast memory on a fast mainboard.


=== Monitors ===
=== Monitors ===


*You cannot change the performance of your monitor, but you should take care that your whole system is in sync at a common base frame rate. In Europe this is 25 FPS:
Ideally, videos should be made in 30/60 frames per second and played on monitors or projectors with a 60Hz refresh rate. But this is not always the case, as for example, the fps and refresh rate standards vary in the UK, US, Europe and other parts of the world. You cannot change the performance of your monitor, but you should take care that your whole system is always in sync at a common base frame rate and refresh rate. So as an example, if your videos are rendered in 25fps, make sure that:
*the video engine (e.g. MXWendler) runs also in 25 fps,
*the monitor has a refresh rate frequency of 50Hz.


** - the video is rendered/produced in 25 fps
{{#mpdftags: pagebreak}}
** - the video engine runs in 25 fps
** - the monitor has a refresh frequency of 75Hz

Latest revision as of 11:35, 5 February 2020

This applies to all different OS and MXWendler versions.

There are six different bottlenecks that have to be passed for perfect video playback:

  • Disk
  • RAM
  • CPU
  • GPU
  • System Busses
  • Monitors

Disk

Videostreams are something from 1 to 100MB/s data transfer, from a standard definition video (480p) to 8K UHD resolutions, and do not forget that having two or more streams reduces the throughput (data transfer rate) exponentially and requires much more resources.

Am I disk limited?

Test

  • Open several streams at the same time until the CPU usage does not grow anymore. You've reached the maximum throughput of your disk.

Solution

  • For best disk performance, use a disk array. Use fast disks ( >= 10k rpm ).
  • Use M.2 SSDs, use SSDs in arrays, they perform up to more than 500MB/s.

RAM

Enough fast RAM is very important for MXW. Normally computer systems have enough RAM ( more than 8gb ) today, so this is generally not a likely source for performance problems.

CPU

MXW is heavily multithreaded and will use every core that your system has to offer. But there are some situations where CPU-intense tasks cannot be parallelized, eg. creating and opening many movies at once or decoding very large videos ( >=4K ).

Am I CPU limited?

Test

Open the task manager.
  • On modern multicore systems, the real situation hides behind the figures: if you cannot parallelize a task, and a single core cannot handle the problem in realtime, you are CPU limited.
  • Open eg. a movie >= 4k ( with demanding content! ) and if it does not play in realtime AND you see a CPU use of ca. 25% on a 4-core system, you are CPU limited.
  • Or play a movie ( ideally with sound ) and while it is playing, constantly open and close other clips. If the first movie starts jittering, you are CPU limited.

Solution

  • The solution is to get a faster CPU (where MHz are in this case more important than the number of cores) or - most of the times easier - reduce server load, eg. split videos, combine outputs, reduce resolutions, etc.

GPU

MXW renders 100% on the GPU, no pixel color is touched on the CPU side.
The performance of GPUs varies widely, some GPUs have 4 pixels processors, some have 1000s. If you have a recent model ( bought since 2015 ), you should not experience much performance problems on the GPU side. But there are important limits, most notably GPU RAM. This means, the dedicated GPU RAM built onto the graphics device. If you run out of GPU RAM, there will be a severe performance loss.

A lot of GPU RAM is used when there are:

  • Many images open,
  • images with very large sizes open,
  • many effects used,
  • extreme large output sizes.

{{#mpdftags: pagebreak}} Am I GPU limited?

Test

  • GPU limitation is reached when it takes a very long time to open eg. dialog boxes.
  • Reduce the output size. Use fewer effects. Delete some images, delete some videos. If the performance rises, you are GPU and/or GPU RAM limited.

Solution

  • A solution may be to rework your visual setup.
Use only the resolutions you need, and keep resolutions below certain limits, especially Power-Of-Two limits.
An image with a width of 1024 will be placed in a 1024 texture.
An image with a width of 1025 will be placed in a 2048 texture.
  • Try (at least) doubling the GPU RAM usage.
  • Under NVidia, for optimal performance, disable the following:
Anisotropic filtering
Antialiasing
Texture filtering
  • Use 'Single GPU Performance Mode' in combination with a device to split the video output.
  • Be sure your Keystone setup ( in fact, this is geometry ) is not too complex for your graphics board.

System Busses

Video data has to be carried from the disk to the cpu to the graphics card. At each stage, the video is decompressed, and the data stream will take more bandwidth.

  • Be sure that your disk bus is as fast as the disk itself. There is no point in connecting a fast RAID to USB 1.1.
  • Always pair fast parts together, e.g use a fast memory on a fast mainboard.

Monitors

Ideally, videos should be made in 30/60 frames per second and played on monitors or projectors with a 60Hz refresh rate. But this is not always the case, as for example, the fps and refresh rate standards vary in the UK, US, Europe and other parts of the world. You cannot change the performance of your monitor, but you should take care that your whole system is always in sync at a common base frame rate and refresh rate. So as an example, if your videos are rendered in 25fps, make sure that:

  • the video engine (e.g. MXWendler) runs also in 25 fps,
  • the monitor has a refresh rate frequency of 50Hz.

{{#mpdftags: pagebreak}}