GL Rendering context switching, GL Objects & cpu/gpu saving
Hi mates,
it made a while. Hope everyone fine here.
A couple of questions more C74 oriented to.
I have some habits using GL contexts and GPU things (like bypassing jit.gl.pix etc) for saving GPU (& CPU if some parameters are flowing too) but I wanted to clarify them. For instance, jit.fx... family, as a comparison, got a bypass internal attributes/features , so nowadays, this is the way, I understand.
Does a jit.gl.node consume something if it is "directed" by changing the drawto to a null context ? Is it "better" to disable it (enable 0) ?
Does a GL 3D objects (I mean gridshape, sketch etc etc) has to be disable too if it is rendered by a jit.gl.node which have been disabled ? More precisely, do I have to disable and/or switch drawto to null the jit.gl.node AND disable GL 3D objects too ?
I used to do both, but maybe the rendering context (jit.gl.node) is the only one to be switched (drawto, etc)
Maybe, some other questions will come here.
Best regards,
Julien
Interested to get more insights too.
From my understanding/experience, it seems that changing the drawto changes the way objects are routed internally and might cause some of them to be reinitialized, possibly allocating memory differently and throwing some errors in the way, while using the enable attribute just makes the drawing stage (mesh/gridshape/model/plato/etc.) or shader pass (pix/slab/shader/pass/etc.) to be ignored.
So I would definitely disable objects (or bypass when relevant) instead of nullifying the drawto.
I was also wondering if it is better to disable all objects drawing to a given [jit.gl.node] rather than just disabling that node, and my few experiments showed that there was no performance benefit for one approach against the other, so I usually stick to just disabling the node. This said, I don't know if changing attributes or params of disabled gl objects (or enabled but drawing to a disabled node) has some impact on performance and if it's worth also gating incoming messages.
Anyway, all this is purely based on experience and intuition without a deep understanding of the rendering pipeline, so take it with a grain of salt, and I'm definitely looking forward reading what more knowledgeable people have to say.
Agree with the notion that enable 0 is lighter weight than drawto foo, and if all you want to do is stop drawing something then you should use enable 0 (or bypass 1 as the case may be).
Also agree that disabling a node is enough to disable bound objects (unless you're doing something unconventional), and that it is probably a good idea to gate inputs if they are coming in at frame rate (though always a good idea to profile as the performance impact may be negligible and not worth the effort).
Thanks TFL for your description.
Rob, thanks too.
Actually, I have some visual contexts in subpatches. These are not occuring at the same time. One context = all the other are disabled.
Depending on the context that I want to enable, I want to completely remove any processes occuring in these patches.
I already have a complex gate system that "protects" anything to flow to all not relevant contexts.
Also, I have a on/off system in all my context which are triggered depending on the current context and which disable/enable everything that needs this (gl objects, textures generation, jit.bang etc)
each context subpatcher is included within another subpatcher that can even easily be mute~ (I mean, a mute~ enable disable MIDI / Audio things in not relevant contexts.
(btw, using these since my very first Max based live performance. nothing crashed yet ;-)
(btw2, I use a similar system when I rarely go to Touchdesigner. There, drawing to NULL is advised. But this push system works completely differently considering rendering as far as I know)
So everything is quite protected already.
In contexts, I have gl objects, all drawing to a specific jit.gl.node included in that context. even my jit.bang is related to this jit.gl.node.
So, and as far as I understand what Robert says,
1/ I'd just have to enable / disable each contexts' unique jit.gl.node and all processes related to that context will be disabled.
2/ Possibly, if I process textures (including the one rendered/capture by the context' unique jit.gl.node, with some jit.fx.XXX within contexts, I can also just bypass these (even if the considered context' unique jit.gl.node wouldn't produce any textures as it would be disabled...)
Do I understand you correctly Rob ?