Good practices for avoiding GPU overload when using jit objects
Hi all!
I am developing a max for live device that play clips in the session view in Live, and these clips send read messages to a jit.gl.movie object that plays them in a jit.world. Everything runs well on my Mac laptop, but recently I got some unusual heating that I thing is related to the jit use and the rendering of these movie clips. I am reducing the dimensions of my clip after they go through jit.gl.movie to 1280x700. After that I applied some jit effects ( color saturation, hue, delay and vhs). What other precautions should I take care in the patching in other to reduce the stress of GPU? Also, I monitor the CPU and GPU of my laptop while using the device, but I am not sure what numbers should I be careful.
I am also monitoring the jit.world in Max with the fps it renders, and I notice that even when the movie clips are not playing, it keeps active the monitoring of fps. I tried giving it the argument enable 0 but it just disappear the window.
Sorry for so many questions in one, I am starting to work with jit and videos.
Hi Mauro, heating is inevitable when the GPU is under load. But unless you notice degrading in performance (due to thermal throttling) there should be no problems. You can download the Stats app https://mac-stats.com/ to monitor the GPU load and temperature (it can easily go over 90°C under stress).
A steady fps from jit.world means the system is not overloaded. Also don't worry about the jit.world rendering while clips are not playing, that doesn't have an impact on the performance.
i answered you on the discord as well, but just want to reply to here since you've provided more details, to say that you can't adjust the dimensions of a jit.gl.movie directly (ie a output_texture enabled jit.movie). it will output textures at the native dimensions of the loaded movie file. if you want to down or upscale, send through a jit.gl.texture @adapt 0 @dim 1200 700 (if you want exact dims) or jit.gl.slab @dimscale .5 .5 (if you want e.g. half res).
Thanks for the replies. I got the mac-stats app to monitor GPU activity and is way more understandable than the monitor included at the laptop. My device is raising up to 46% in the gpu when all the effects are on. Specially delay effect is the more demanding one on the gpu.
I wanted to add text on top of the video clips, and I was wondering how much stress this could cause to the gpu but even when is 3d text, it didn't add much. Now I want to experiment overlaying png pictures on top of the video clips, so I will see if this would be out of range for my laptop or not. Ideally, I would like to develop this device so pretty much anyone can use it on any OS, but maybe is too much to ask?
46% GPU usage is very low. GPU load is not the same as CPU load, it tends to be much more consistant across time since basically the same process is repeated frame after frame. And as long as you don't reach 100%, there is nothing to worry about more or less.
The load will depend on how heavy the process itself is (how many objects to draw, how many vertices these objects have, how complex drawing and post-processing shaders in use are), and how many frames per second you want to generate.
Displaying still images like PNG pictures is very light, you could probably display dozens of it with no issue.
Ideally, I would like to develop this device so pretty much anyone can use it on any OS, but maybe is too much to ask?
If you're asking to yourself, you only have the answer :)
At least, it sounds like like a very feasible project!
i can see where you are going, some people do similar things for audio.
for audio it is easy; the patch can measure the other users computer performance by running a bigger audio process for a moment and then see how much CPU that uses using the dspstate object.
for GPU power one can only do that manually (as the other user) or guess approximate limits of certain graphics cards or mac models.
those with more jitter experience might add if and how it can make sense to perform a little jit.gl or jit FPS test to find out about the enviroment.
when your own jitter patch also completely relies on a steady frame clock you can test the enviroment with your actual process - if it delivers a max of 100 FPS, simply limit the main clock to 75.
for nonrealtime processes it is impossible to spare out a percentage of the available processing cycles... to my knowledge (but what do i know)