6l20

Working on a big project I'm experiencing some general performance issues with max for live and open gl .

I own both Live and Max, working on a mid 2015 mac book pro with 2,8 GHz Intel Core i7 and an AMD Radeon R9 M370X 2048 MB graphics card.

I have 2 different patches, doing heavy processing on realtime video.

If they are both used as Max Midi Effects in M4L, I am experiencing massive fps drops, making them impossible to use.

If both patches run independently in Max, same thing, massive fps drops.

If one runs in M4L, the other in Max , they work just fine.

So it's not that my cpu or gpu can't deal with that many calculations, and I am sure there is a very simple explanation to that, like multiprocessor use in different instances of a software or stuff like that, but I need help to figure it out and to find a way to solve this.

I will attach my patches if requested, but I really do not think this is relevant as my question is more general than their non-optimization :-).

Hi All.
Working on a big project I'm experiencing some general performance issues with max for live and open gl .
I own both Live and Max, working on a mid 2015 mac book pro with 2,8 GHz Intel Core i7 and an AMD Radeon R9 M370X 2048 MB graphics card. 

To explain it in a simple way :
I have 2 different patches, doing heavy processing on realtime video.
If they are both used as Max Midi Effects in M4L, I am experiencing massive fps drops, making them impossible to use.
If both patches run independently in Max, same thing, massive fps drops.
If one runs in M4L, the other in Max , they work just fine. 

So it's not that my cpu or gpu  can't deal with that many calculations, and I  am sure there is a very simple explanation to that,  like multiprocessor use in different instances of a software or stuff like that, but I need help to figure it out and to find a way to solve this.

live-and-max-instances-performance-issue

Hm, if I had to guess, there's some sort of issue that arises when they are running in the same environment. Meaning when both are running in Live, or both are running in Max. Maybe an issue some shared resources/data/inputs? Hard for me to hazard more than a guess though. Pretty dependent on what the patches are doing, making them pretty relevant actually ;)

I did some more tests, and it seems that this is the case with pretty much any patch that requires sort of heavy processes. Other thing , if I simply copy and paste the max application in the applications folder, if I open one patch with "MAX" and the other one with "MAX copy", they both run smoothly... Really looks like a multithread/multiprocess management issue. or configuration on my laptop ?

Some things are not optimized, or even do not make sense at all in them ( like outputing a jit.movie to a videoplane to get it out again as a matrix through a jit.world @output_matrix 1, totally ridiculous but close to what I need in the complete version of my project using syphon input that I can only get in the openGl world, and need as a matrix for recording and looping purposes); but again I am more interested in understanding what's going on rather than in optimizing these rough patches.

Thanks for your reply Evan!
I did some more tests, and it seems that this is the case with pretty much any patch that requires sort of heavy processes. Other thing , if I simply copy and paste the max application in the applications folder, if I open one patch with "MAX" and the other one with "MAX copy", they both run smoothly... Really looks like a multithread/multiprocess management issue. or configuration on my laptop ?

Some things are not optimized, or even do not make sense at all in them ( like outputing a jit.movie to a videoplane to get it out again as a matrix through a jit.world @output_matrix 1, totally ridiculous but close to what I need in the complete version of my project using syphon input that I can only get in the openGl world, and need as a matrix for recording and looping purposes); but again  I am more interested in understanding what's going on rather than in optimizing these rough patches.

The first patch is already very CPU intensive.

Your jit.movie objects could include "@output_texture 1 @colormode uyvy" to send the image directly to the GPU.

With many instances of movies needing to be decoded at the same time, you could see better performance using the hap codec and external.

You could/should define a master qmetro in one of the patches and send it to the other using a send/receive pair. ("s metro / r metro").

Just some general thoughts:
The first patch is already very CPU intensive.
Your jit.movie objects could include "@output_texture 1 @colormode uyvy" to send the image directly to the GPU.
With many instances of movies needing to be decoded at the same time, you could see better performance using the hap codec and external.
You could/should define a master qmetro in one of the patches and send it to the other using a send/receive pair. ("s metro / r metro"). 

Thanks for your reply and your advice Pedro.

It does help optimizing the patches without any doubt.

But I purposely made these patches heavy. I could have demoed my issue with pretty much any patch really. And I did try the same thing with totally different patches, and whatever they are made of, same problem and same solution. 2 CPU heavy patches run smoothly in different instances of Max, suffer massive performance glitches when opened in the same instance.

I know the first patch is very CPU heavy, but I also know that my laptop is clearly able to do deal with it... The question is : why is it able to deal with it only if split between two instances of Max ??? I could understand it if, as Evan mentioned, both patches had some shared send/receive or input/output causing synchro/orders problems. But as you can see this is not the case here.

The more I think of it and try different things, the more it looks to me like Max does not separate threads on different CPU cores properly, and that creating a copy of max or using one patch in max, the other in m4l is a way to force this happening...

Any help is still very much appreciated !

Thanks for your reply and your advice Pedro.
It does help optimizing the patches without any doubt.
But I purposely made these patches heavy. I could have demoed my issue with pretty much any patch really. And I did try the same thing with totally different patches, and whatever they are made of, same problem and same solution. 2 CPU heavy patches run smoothly in different instances of Max, suffer massive performance glitches when opened in the same instance.
I know the first patch is very CPU heavy, but I also know that  my laptop is clearly able to do deal with it... The question is : why is it able to deal with it only if split between two instances of Max ???   I could understand it if, as Evan mentioned, both patches had some shared send/receive or input/output causing synchro/orders problems. But as you can see this is not the case here.

The more I think of it and try different things, the more it looks to me like Max does not separate threads on different CPU cores properly, and  that creating a copy of max or using one patch in max,  the other in m4l is a way to force this happening...

Any help is still very much appreciated !


Unfortunately, you're right in your suspicion about Jitter and multithreading so, for now, the only workarounds are "optimization" and dividing processing using independent applications (Max+Max, Max+Live).

https://cycling74.com/forums/multithreading-suggestions/

https://cycling74.com/forums/max-7-and-the-level-of-multithreading-optimisaton/

https://cycling74.com/forums/jitter-multithreading-in-max-7/

https://cycling74.com/forums/feature-request-expanding-the-scope-of-parallel-processing/

Hello again, Sylvain.
Unfortunately, you're right in your suspicion about Jitter and multithreading so, for now, the only workarounds are "optimization" and dividing processing using independent applications (Max+Max, Max+Live).

See:
https://cycling74.com/forums/multithreading-suggestions/
https://cycling74.com/forums/max-7-and-the-level-of-multithreading-optimisaton/
https://cycling74.com/forums/jitter-multithreading-in-max-7/
https://cycling74.com/forums/feature-request-expanding-the-scope-of-parallel-processing/


Wow. Thanks much for your reply Pedro. This and your links explain it all, and explain also why I so often feel that jitter can only use that many percent of my computer's resources.

@Cycling74 team, any update on when multithreading will be implemented for jitter, or at least a workaround will be offered ( a jitter equivalent to poly~ maybe ?)

Now another question that is probably unrelated . Any idea why the fps drop big time when I toggle my "main" window fullscreen, and this only on an external hdmi or miniDP->DVI screen, not on the main one ?

Wow. Thanks much for your reply Pedro. This and your links explain it all,  and explain also why I so often feel that jitter can only use that many percent of my computer's resources. 

Now another question that is probably unrelated .  Any idea why the fps drop big time when I toggle my "main" window fullscreen, and this only on an external hdmi or miniDP->DVI screen, not on the main one ?

It won't make any difference if multithreading is implemented in Jitter in your case because Live only allows a single-threaded instance for Live plugins..

you will have significant performance improvements and resource utilization if you enable output_texture on your jit.movie objects, as suggested above. additionally, using jit.gl.asyncread rather than jit.world matrix_output might increase performance and utilization.

i'm not certain on this, but i think the HDMI port forces use of the integrated GPU on MBPs, rather than the dedicated AMD, which might account for the FPS drop with fullscreen on external display.

you will have significant performance improvements and resource utilization if you enable output_texture on your jit.movie objects, as suggested above.  additionally, using jit.gl.asyncread rather than jit.world matrix_output might increase performance and utilization.

i'm not certain on this, but i think the HDMI port forces use of the integrated GPU on MBPs, rather than the dedicated AMD, which might account for the FPS drop with fullscreen on external display.


Hi Rob and thanks for your reply. I managed to solve my fullscreen issue by "faking" a fullscreen : jit.window @border 0, resized to my entire screen (info from jit.displays) Visually no difference compared to a "real" fullscreen, but fps-wise, massive one. Would the HDMI port GPU issue you mention still be applicable ? What is really happening, apart from a window resize, when enabling fullscreen on a jit.window ?

Regarding jit.movie @output_texture 1, unfortunately in my project this is not possible. I'll try to make the long story short :-) :

I used jit.movie on the patcher I posted here, but my project is a real-time audio video looper, and I need the images to be in the "matrix" world at some point to be able to record them to disk. I have great results recording and reading back raw matrices using jit.matrix, that I synchronize with a groove~ object (when recording audio, I actually use a third channel of "audio" to keep frame numbers in my buffer~ allowing a perfect audio/video synch when reading back).

As output_texture is not an option for a jit.matrix, and as jit.movie cannot decode raw jitter matrices, unless there is a workaround I am not aware of I do not see how I can avoid being in the "jitter matrix" world when reading back.

I tried a much simpler and more logical way of recording and reading back synchronized audio and video with jit.vcr or jit.record and jit.movie, but the looping options of jit.movie do not allow for the beautifull audio glitches and smoothness I can achieve with groove~ and extremely close loop points.

Unless there is a way I do not know about to store with jit.matrix or any other object, with zero compression time, a single frame at a very specific time, in a format that jit.movie can read back ?

In the end, I do not mind building a standalone with some parts of the process and keep the rest in live. Works beautifully now. But the only thing is, whenever I build a standalone application with my machine, it crashes upon opening on any other computer. Same thing if I create the application with a friend's computer, won't open on mine. Same os version and laptop specs... I dont know why with this project I have the feeling that there's always something to keep me from finishing it !

Hoping you'll have answers for the 3 issues mentionned in this very short post...

Hi Rob and thanks for your reply.  I managed to solve my fullscreen issue by "faking" a fullscreen : jit.window @border 0, resized to my entire screen (info from jit.displays) Visually no difference compared to a "real" fullscreen, but fps-wise, massive one.  Would the HDMI port GPU issue you mention still be applicable ? What is really happening, apart from a window resize, when enabling fullscreen on a jit.window ?

Regarding jit.movie @output_texture 1, unfortunately in my project this is not possible. I'll try to make the long story short :-)  :
I used jit.movie on the patcher I posted here, but my project is a real-time audio video looper, and I need the images to be in the "matrix" world at some point to be able to record them to disk. I have great results recording and reading back raw matrices using jit.matrix, that I synchronize with a groove~ object (when recording audio, I actually use a third channel of  "audio" to keep frame numbers in my buffer~ allowing a perfect audio/video synch when reading back).
As output_texture is not an option for a jit.matrix, and as jit.movie cannot decode raw jitter matrices, unless there is a workaround I am not aware of I do not see how I can avoid being in the "jitter matrix" world when reading back.
I tried a much simpler and more logical way of recording and reading  back synchronized audio and video with jit.vcr or jit.record and jit.movie, but the looping options of jit.movie do not allow for the beautifull audio glitches and smoothness I can achieve with groove~ and extremely close loop points.
Unless there is a way I do not know about to store with jit.matrix or any other object, with zero compression time, a single frame at a very specific time, in a format that jit.movie can read back ?

when going fullscreen the gl context and resources are destroyed and rebuilt.

the resizing the window as you've described is a fine workaround if you're having issues with fullscreen. another workaround to try is to not enable rendering until after you've positioned and fullscreened the window.

does the standalone crash, or does it say can't open because it's damaged or something like that? if it's the latter, you have to allow apps from anywhere in the Mac system preferences, security & privacy setting. if it's the former, i'd send a message to support.

when going fullscreen the gl context and resources are destroyed and rebuilt. 

does the standalone crash, or does it say can't open because it's damaged or something like that? if it's the latter, you have to allow apps from anywhere in the Mac system preferences, security & privacy setting. if it's the former, i'd send a message to support.


The standalone crashes : I get the message "NAME OF MY APP" quit unexpectedly. Click reopen....

I'll send a message to support. Do you think it can be because I use an object that's not in the standard Max library (jit.gl.syphonclient) ? I did specify in the script to include it.

The standalone crashes : I get the message "NAME OF MY APP" quit unexpectedly. Click reopen....
I'll send a message to support. Do you think it can be because I use an object that's not in the standard Max library (jit.gl.syphonclient) ? I did specify in the script to include it.
Thanks


LIVE AND MAX INSTANCES PERFORMANCE ISSUE