share textures in different jit.gl.renders


    Jan 08 2009 | 11:19 pm
    hi
    for a project i work with multiple video outputs (dvi) so i figured out i have so create differnt jit.gl.render's one for each screen. Is there a way to share jit.gl.textures between those jit.gl.renders ? now it looks like i have to give the name of the render environment to a texture. i dont wat to create each texture again for every output ( on my system i can have up to 8 outputs...)

    • Jan 08 2009 | 11:31 pm
    • Jan 09 2009 | 10:18 am
      Hello,
      I can't get it working. Are you sure about @shared_context ?
      thank you.
    • Jan 09 2009 | 2:28 pm
    • Jan 09 2009 | 7:40 pm
      That last 4 context one *does not* work for me.
      ou have two jit.gl.textures chained there, and if I remove the redundant texture, I get white video planes on everything but context 1.
      If I have that the redundant texture, I have some gobbly gook bullshit that isnt the proper image.
      Im going to say there is something wrong were with the order of GL operations or some state leak, that does not happen with the removal of that redundant texture. But im also guessing.
      Either way, all you have demonstrated is something that works on your hardware, not on all.
      The proper, supported method is to use shared context as explained.
    • Jan 09 2009 | 7:43 pm
      Also, im not so sure the order of the shared contexts matter (ie which contexts shares with which in what order), all that matters is that it indicates it allows shared resources across the two (or more) contexts, but I have honestly not fully explored the ramifications of them.
      In other languages/GL environments one can do:
      context1
      context2 @shared_context context1
      context3 @shared_context context1
      context4 @shared_context context1
      and it basically allows all 4 to share textures, vbos etc (as I understand it).
    • Jan 09 2009 | 8:01 pm
    • Jan 09 2009 | 8:05 pm
      Well, either way, I really would not rely on it. If you need shared context, use @shared_context ;)
      I think this is something with jit.gl.texture, as I discovered it worked if I dicked with removing/re-instantiating jit.gl.texture (the redundant one I mentioned).
      If you dont have that extra jit.gl.texture, no joy. So, Id say nice find, but, again, it seems more like errata than bonus functionality ;)
    • Jan 11 2009 | 1:25 am
      so i tried it with two contexts and it worked
      but cant get to work with 3 contexts
    • Jan 11 2009 | 1:34 am
      ...and when i actualy move the jit.windows to external screens on different videocards ( i have 4) i get a total system freeze and have to manualy reboot.....
      :(
    • Jan 11 2009 | 5:40 pm
      haven't tested it but it looks like shared_context only works with outputs on the same videocard....
    • Jan 12 2009 | 1:37 am
    • Mar 01 2009 | 2:58 pm
      jsrousseau wrote on Sun, 11 January 2009 03:06yep it happens, I normally use the triplehead2go from matrox, so 1 videocard out for 3 screens.
      have had good results with this too. i had to setup an installation with 3 jitter openGL projections on hardware which wasnt my own, a multi-videocard PC. didnt work out. the matrox triplehead on my macbook pro's single output saved the day in the end.
      Quote:which makes sense, unless you cards can share ressources
      now that you mention it... that might very well have been the reason
    • Mar 01 2009 | 3:50 pm
      btw, jitter recipe 39 can help you out: https://cycling74.com/story/2006/2/17/153427/406