Multiple screens in Jitter

Apr 19, 2010 at 8:42am

Multiple screens in Jitter

Hi,

i am making a patch for a macbook (2×2.66 GHz Dual Intel Xeon with 5 GB FB-Dimm RAM) with 5 screens. It has 2 videocards (NVIDIA GeForce 7300 GT) with 4 outputs, but i need an extra screen so i can have a separate monitor as well. This is how my hardware is wired now:

videocard 1:
- Matrox dualhead splitter for 2 projectors resolution 2048 x 768 (sent to 2 projectors in 1024 x 768 resolution)
- 1 projector with resolution 800 x 600

videocard 2:
- monitor 1280 x 1024
- projector 800 x 600

So basically i have 5 screens, with different resolutions.

In max/jitter i have created 4 jit.qt.movie objects, connected to 4 jit.gl.slab objects. These slabs are connected to 4 jit.gl.videoplanes which are rendered to a big jit.window and scaled and positioned so they fit each projector screen.

When i load 4 movies of 800 x 600 resolution, and compression PhotoJPG, the framerate is about 12….which is not very high.

My question is: am i doing the right thing in this patch? Or is there another way to make it more efficient? It is the first time that i use this kind of setup (with 5 (!) screens). My experience with resolutions and such, is that the framerate usually goes up when it ‘fits’ the resolution of the projector….maybe you guys have experience with this.

Thanks in advance for any tips!!

gr

#49852
Apr 19, 2010 at 10:42am

Without calculating anything I can only say i’m not terribly surprised the thing is heavy, but I think there’s still a chance it possible, I think we used 4 x half HD (= full HD) here with success, which is not too different from your amount of video, on an imac.

Your routing of the movie seems ok (so is photoJPG). I’d probably use jit.gl.texture myself, but I don’t think it should make a difference. Make sure the dim of the jit.gl.videoplane is 2 2, as your videocard isn’t very fast.

You can use transform_reset 2 on the videoplanes, so you don’t have to position them exactly. I’m not quite sure whether this gets rid of depth checking as well, you should try it out though.

Framerate is usually better when movies fit the resolution of the output window, but when you’re using textures it doesn’t matter i think, everything is looked up anyway. But you should make sure the texture(or slab) is the same size as the movie. In case you’re really stuck, the best solution would probably be to resize your movies and textures, and still map the texture to the full screen (this will cause less bandwith usage on your CPU and bus when sending the movies to the videocard, while the GPU can scale the texture). Just my thoughts, hope it helps at all. Good luck!

#179015
Apr 19, 2010 at 12:47pm

you have one jit.window streched over all the screens? lol .

for every gpu you need at least one jit.gl.render
better have one for every videooutput

in your case you would have 3 jit.gl.render’s with 3 jit.window’s
(the dh2g counts for one)

on the card with the dh2g and one projector you can use shared_context between the two jit.gl.render ‘s
but you cant share context between to separate gpu’s .

here i was doing a project with 7 projectors on one macpro http://www.vimeo.com/4293627

#179016
Apr 20, 2010 at 12:09am

just to reiterate.
create a separate gl context (jit.gl.render and jit.window combination) for each graphics card you are using. two ports on the same graphics card (or the ports from something like a matrox dual/triple head) can either use the same graphics context (by setting the @rect attribute of the window to span across the ports output) or they can have distinct, but shared render contexts.

at initialization time, it is recommended that you rebuild all the graphics contexts that are not the main output window (so any context where you must set the @rect attribute of the jit.window to anywhere other than the primary monitor), by toggling either the @floating or @border attribute of the jit.window.

#179017
Apr 20, 2010 at 9:56am

Great feedback so far, really helpful. Thanks. I will get to rebuilding the patch soon. Will let you know if the fps get a bit higher ;)

#179018
May 5, 2010 at 9:13am

So i have rebuilt my patch, and the fps is good now. 3 jit.gl.render objects for each gpu seems to do the trick…

I still have a problem though: although the fps in the jit.gl.render objects is showing around 25 fps, the video is not fluent, it has little hiccups…any idea how to resolve this?

Thanks so far, your feedback is much appreciated!

#179019
May 5, 2010 at 7:09pm

are you using colormode uyvy?
have you looked at the vade video playback optimization tips?

http://abstrakt.vade.info/?p=147

otherwise, post just the video playback part of your patch, and we may be able to offer suggestions.

#179020
May 5, 2010 at 8:56pm

Yep, using the uyvy colormode for optimalisation, followed most of the stuff of Vade. I will look into these tips more intensively, trying to get everything as optimal as possible. I can post an example patch tomorrow, but i figure the playback hiccups have to do with the computer i am running it on..? An update tomorrow…performance in two weeks so maybe i will eventually have to accept the flaws.

#179021
May 5, 2010 at 9:08pm

Are all of your source MOV files being played off of the same disk? If so, you may want to try spreading them over more than one disk, or going with a RAID 0 of some kind.

#179022

You must be logged in to reply to this topic.