Help Optimizing Live Performance Jitter Patch – Questions About GPU Processing, OpenGL Confusion, Save/Recall Issues, and Scaling Artifacts

1. No straightforward way, just a few general good practices to have, then it's really patch-specific in my opinion. Make sure you are using @output_texture 1 on your [jit.movie] and that you stay in the gl realm all the way, unless those textures are meant to affect some geometry/vertices and [jit.gl.tf]+[jit.gl.buffer] doesn't work for you in this regard, in which case you might need [jit.gl.asyncread] to read the GPU textures back to CPU matrices without too much impact on the performance. The patch you shared isn't working (it's missing all its bpatcher dependencies), but from what I can see, the [p Mosaic] and [jit.plume] part would benefit from being converted to jit.gl objects. Most if not all objects you are using here already have a jit.fx counterpart. I assume what is coming from the [r sw_1/2/3/4/5] are textures already, but not what you get from OBS, so you need to put a [jit.gl.texture] just after your [jit.ndi.receive]. Or if for some reason you want to keep the Mosaic process in the matrix realm, try throwing a [jit.gl.asyncread] before the first [jit.rota] and see how it goes (might need some specific routing for the matrices coming from OBS as they wouldn't need to be asyncread).

2. As far as I know [jit.gl.pix] [jit.gl.slab] and [jit.fx.*] need regular routing just like using [jit.gen] or other jit. objects with matrices. Some objects like [jit.gl.pass], [jit.gl.node] can be used to apply effects more "globally" without patch cord routing though. About how to work with matrices and textures, it's basically what I said in 1: if you work with textures, stay as much as you can with jit.gl/jit.fx objects from the beginning. Converting matrices to textures in straightforward with [jit.gl.texture] but is a bit slow when done every frame, and converting textures to matrices can be done more efficiently with [jit.gl.asyncread] if you don't need 100% accurate timing, but should still be avoided when possible. You are working with jit.ndi objects here which sadly aren't compatible with textures, so you have to use these methods with them.

3. [pattrstorage] can only work from its own patcher level down to any subpatcher level. So if you encapsulated it in a bpatcher, it won't be able to see what are in sibling patchers or in your main patcher. A workaround is simply to keep [pattrstorage] in your main patcher but have all the logic and UI to work with it in your [bpatcher]. I actually do that quite often as it helps for maintainability.

4. There is no magical way to upscale textures. You're adding data to the source, and that new data need to be guessed from the existing data, either by linear interpolation (that's what [jit.gl.texture @dim 1920 1080] does by default), either without interpolation which will give a clean pixelated look (add @filter none to [jit.gl.texture]). The patcher below gives you an example for this. Nowaday GPU has fancy features like DLSS for Nvidia or FSR for AMD which upscale images using AI in realtime, but as far as I know it is only accessible for the final output and cannot be controlled from Max.

Also, your specs don't mention a dedicated GPU. Do you have one? Or are you working on the integrated GPU of your CPU (Intel UHD graphics 770)? If you have one, make sure Max is running on it instead of the integrated GPU!