Peter Pajchel

I'm having problems with drawing jit.gl.slabs to different contexts when running 3 jit.windows on 3 different GPUs. My setup is a Mac Pro with 4 x Nvidia GT 120 cards

This example patch works on one GPU. But when I have place 3 jit.windows on three separate GPUs I can only see processing in my initial context (fa) and nothing in  the other two (foo and santa).

When I send a drawto message to the jit.gl.slabs I get this this error:

jit.gl.texture: unable to create texture!

jit.gl.texture: error entering unbind: GL Error: Invalid value

jit.gl.pbuffer: error binding texture: GL Error: Invalid operation

If I remove the jit.gl.slabs I can switch between the different contexts with out any problems.

Am I missing something, or is there a problem here? Any tips / pointers to what I'm doing wrong, would be greatly appreciated.

I'm having problems with drawing jit.gl.slabs to different contexts when running 3 jit.windows on 3 different GPUs. My setup is a Mac Pro with 4 x Nvidia GT 120 cards
(last version of MAX/ Jitter OSX 1.6.2.)

jit.gl.texture: unable to create texture!
jit.gl.texture: error entering unbind: GL Error: Invalid value
jit.gl.pbuffer: error binding texture: GL Error: Invalid operation

If I remove the jit.gl.slabs  I can switch between the different contexts with out any problems. 

drawing-jit-gl-slab-to-contexts-on-4x-gt120-mac-pro

i won't have a multi-card setup to test on until after the holidays, but why are you not also changing the context of the slab along with the texture and gridshape?

Yes, that was my thinking in the first place to send a drawto message to the jit.gl.slabs. It seamed like the obvious thing to do.

followed by some artifacts and crash. sometimes in works. very confusing

I have also made various trigger sequences of the drawto message and also tried disposing the slab before sending the drwato message and then reading it again. I'm stuck. After doing all kinds of max/jitter Voodoo for two looooong days. So, I'm desperate for some help ;-) Thanks for looking into this problem.

followed by some artifacts and crash. sometimes in works. very confusing 

I have also made various trigger sequences of the drawto message and also tried  disposing the slab before sending the drwato message and then reading it again. I'm stuck. After doing all kinds of max/jitter Voodoo for two looooong days.  So, I'm desperate for some help ;-) Thanks for looking into this problem.

would you mind explaining a bit more about what you are trying to accomplish? specifically the end result.

why do you need to be able to dynamically switch the contexts of your opengl objects across the GPUs?

there are a lot of places to get tripped up with multiple opengl contexts and multiple GPUs, but usually a solution can be found.

I'll do my best, the final patch has on one side 16 "source" channels, meaning 16 bpatchers containing a jit.qt.movie / some slabs for adding alpha and basic br-co-sa. The result of this processing at the "source" is sendt as a texture to one or more "destination" video planes (in the current patch I use jit.gl.gridshape") in total there are 32 "destinations" .

Here is a picture of the final patch to help my explanation: 

http://dl.dropbox.com/u/1479690/patch.tiff

So to sum it up, its a multi channel video mixer. In previous productions I have been using a matrox tripelhead2go splitter to run 3 projectors, but In my current project I want to be able to run more than 3 projectors from a Mac Pro.

If I have a "videosource-destination" combination running on one projector I want to be able to move this to another projector (another context). Dynamically changing where the combination of slab/texture/gridshape is rendered. So the patch could run in just one gl context or spread across several contexts (depending on how many projectors are connected) if needed.

Hope this explanation clears things up a bit.

I'm curious what kind of results you are getting on your multi card setup with my example patch?

I'll do my best, the final patch has on one side 16 "source" channels, meaning 16 bpatchers containing a jit.qt.movie / some slabs for adding alpha and basic br-co-sa. The result of this processing at the "source" is sendt as a texture to one or more  "destination" video planes (in the current patch I use jit.gl.gridshape")  in total there are 32 "destinations" . 

Here is a picture of the final patch to help my explanation: http://dl.dropbox.com/u/1479690/patch.tiff

If I have a "videosource-destination" combination running on one projector I want to be able to move this to another projector (another context). Dynamically changing where the combination of slab/texture/gridshape is rendered.  So the patch could run in just one gl context or spread across several contexts (depending on how many projectors are connected) if needed.  

Hope this explanation clears things up a bit. 

I'm curious what kind of results you are getting on your multi card setup with my example patch?
Are you having the same errors?

with your original patch, i can drag one of the windows to a second GPU and have no errors when i tell the gl objects to draw to that context. i can eventually crash my whole system if i drag the "fa" context back and forth across the GPUs and toggle drawing to that context.

however, since the window is created on the "main" GPU, and then dragged to the secondary GPU, i believe the context is not actually on that 2nd GPU, but somehow shared between the two. this can cause a significant drop in performance. the solution is to set the @rect attribute of the secondary jit.window to the coords of the secondary display (using jit.displays helps), and re-instantiating the context (toggling @fsaa or @floating does this).

when i modify your patch so that the windows are instantiated in the correct display coords, and then switch the drawto attribute (including the gl.slab) i get the stream of errors that you describe. re-instantiating the gl context (by toggling @fsaa) silences the errors.

so switching the drawto context of gl objects across multiple GPUs does not appear to be something you should do dynamically.

unless i'm misunderstanding, you should be able to determine the number of displays present (using jit.displays) and set the @rect of your windows and @drawto of all your gl objects at initialization time, and after setting everything, re-creating the context by toggling @fsaa on the windows.

then you can just send your qt.movies to the different contexts (before the slab chain) and have each context duplicate each of the slab chains.

not sure if this helps much, but i'd be happy to elaborate on anything.

however, since the window is created on the "main" GPU, and then dragged to the secondary GPU, i believe the context is not actually on that 2nd GPU, but somehow shared between the two.  this can cause a significant drop in performance. the solution is to set the @rect attribute of the secondary jit.window to the coords of the secondary display (using jit.displays helps), and re-instantiating the context (toggling @fsaa or @floating does this).

not sure if this helps much, but i'd be happy to elaborate on anything.


when i open your patch i first drag the windows to the right gpu and the start the metro

like what rob says first put the windows on the right gpu.

had the same problem with a project i did last year with 7 outputs using shared_context

had to put the right jit.windows on the right gpu or else kernel panic....

maybe im wrong but with jit.displays you are not able to see which monitor is on which gpu.

which is a big pain in the *** . Have to do it manualy . If osx somehow changes the monitor setup it often rearrange the way windows are positioned and then the patch sends a jit.window into void or on a wrong display/gpu. and it crashes again ....

dont have any errors on my system
macpro 2008 with 4 ati 2600XT

when i open your patch i first drag the windows to the right gpu and the start the metro
like what rob says first put the windows on the right gpu.

had the same problem with a project i did last year with 7 outputs using shared_context
had to put the right jit.windows on the right gpu or else kernel panic....

maybe im wrong but with jit.displays you are not able to see which monitor is on which gpu.
which is a big pain in the *** . Have to do it manualy . If osx  somehow changes the monitor setup it often rearrange the way windows are positioned and then the patch sends a jit.window into void or on a wrong display/gpu.   and it crashes again ....

the project : http://www.vimeo.com/4293627


One trick I have used in the past to rebuild the context is to send a drawto message to jit.gl.render and have a cpu side named matrix. so basically I send [drawto matrix, drawto actualglcontext( message, and that used to solve a few issues (some texture binding issues, and this force a window and context to live on the right gpu issues).

I used to switch border on/off for jit.window to force the context rebuild.

Would it be possible to add a message to jit.window or jit.gl.render to rebuild context?

Thanks for all the good feedback on this issue!

After some more testing I have to agree with Robs recommendation:

"switching the drawto context of gl objects across multiple GPUs does not appear to be something you should do dynamically"

However, sending the jit.gl.slab straight to the jit.gl.gridshape (not using jit.gl.texture) and re-instantiating the gl contexts at the jit.gl.rendrer after sending the drawto message to the other gl objects gave me no crashes but some inconsistent slab drawing, and some occasional jit.gl.texture / jit.gl.shader errors. So Vades tip kind of helped, but it still has glitches that have to be fixed (ses example patch for further explanation)

Maybe if I had more time I would be possible to make this work, right now I need to come up with something that works 100% ASAP, So I'm considering replacing the 4 x GT120 configuration with:

1 x GTX 285 = with a multi-GMX setup from Matrox running 6 projectors at a resolution of 1024x768

via two Matrox tripelhead2go Digital splitters.

I've done some initial testing with two splitters on one of the current GT 120 cards in my setup and have

I have a good feeling about this hardware configuration for this project.

However, sending the jit.gl.slab straight to the jit.gl.gridshape (not using  jit.gl.texture) and re-instantiating the gl contexts at the jit.gl.rendrer after sending the drawto message to the other gl objects gave me no crashes but some inconsistent slab drawing, and some occasional  jit.gl.texture /  jit.gl.shader errors. So Vades tip kind of helped, but it still has glitches that have to be fixed (ses example patch for further explanation)

1 x GT120 = running GUI/Patch monitor
1 x GTX 285 = with a multi-GMX setup from Matrox running 6 projectors at a resolution of 1024x768
via two Matrox tripelhead2go Digital splitters.

I've done some initial testing with two splitters on one of the current GT 120 cards in my setup and have
no GL context switching issues. 

I have a good feeling about this hardware configuration for this project.
What do you think? 

my advice would be to stick with four cards and eliminate context switching.

Drawing jit.gl.slab to contexts? on 4x GT120 Mac Pro.