Hey, hoping someone can help me out here.

I've been getting into using more and more complex objects in GEM and I'm wondering if I should start using openGL objects. In my understanding, these would take the load off of my processor and ram and put it on my video card, leaving my processor free to perform the all important audio and control functions. Is this correct? Aslo, where can I go to gain an understanding of how openGL functions within GEM? It seems that the documentation ends by explaining that GEM is a wrapper for openGL, but how does one implement it?

--Thanks,
--Nestor

I can't find it now but I saw a list of the GEM objects that 'wrap' OpenGL functions somewhere. I imagine these are wrappers in the sense that they allow you to call x. function as a pd object. I know nothing about these - maybe if you were to grab a basic OpenGL sample & try to translate the function calls & program flow from c or c++ using the GEM & other pd objects...it all might become clearer. Please post back if you do - I'd love to know

Determining how much of the processing would get offloaded to the GPU on a video card - I think that would be a bit of a black art. I would just try to check if CPU load changes depending on how you build & rebuild your patch.

I would expect that the higher-level GEM objects are already doing this (using the GPU).

A

This is tricky business, definitely a black art. Be careful too, because if done wrong, you could actually decrease performance. Try to avoid the situation where objects move between CPU->GPU->CPU or GPU->CPU->GPU paths (usually introduced by sloppy code {my fault!} or by accident) which will bog down your chains. I don't have much experience in this regard with GEM, but I have had issues of the like within Jitter in the past until I recoded my patches to keep CPU and GPU code from being too interdependent. Anyone else seen these issues?

I received the most benefit by keeping most of the processing I was able to code in slabs (the jitter term, aka opengl processing) and only relying on simple CPU driven matrix math on either sides of the slab render chain.

yep that's a situation that came to mind, Data moving around needlessly. & how to determine which subsystems a particular object or relationship of objects is going to hit. Don't let us stop you though - sounds like good old pd insane fun

Using a profiling tool that will tell you what your graphics card vs. CPU are doing could also be useful. That's not something I know much about sorry.

A

Alright, it seems like both of you have taken a stab at what I intend to do, which I am already doing with GEM alone. I'm using mostly the canonical pd objects to do the control stuff, and would only put opengl at the end of a gem chain. I'm just wondering if it makes sense to try openGL or just to stick with GEM. I don't have any idea what openGL provides, or what I could do with it that I can't already do with GEM objects.

It wouldn't hurt to learn as you go w/ the GEM objects, you could do some elite hacks with that info. That kind of stuff should hold between graphics work in Pd or Processing for example.

Yes, you need to keep going. That's what open source is all about. You could do far worse than writing up whatever you discover too. I'd stick with GEM & see where that gets you as it basically is OpenGL repackaged.

A