Forums > Jitter

How to force projectors to scale Jitter's output?

January 5, 2011 | 2:08 pm

I’m starting to put together a permanent installation with a new Mac Pro and two GPUs feeding five Panasonic PT-AE4000 HD projectors and a control screen. Sources will vary, so for now I’m just using jit.qt.grab @640 480. I think I’ve read and followed all the relevant posts in putting together the attached patch, which uses shaders, a separate context for each GPU output, and detects and positions each of the windows to the right coordinates before rendering. I was rather hoping, however, that by setting the projectors to their lowest resolution (640×480), as in the top right of the patch, that when I went full-screen the shaders in the projectors would do the work of up-converting Jitter’s output. Unfortunately, the 20 fps or so that I enjoy before going full-screen plummets to about 8 fps afterwards, so obviously that’s not happening. Is there a way of outputting images in Jitter that will force the projectors to do the necessary scaling rather than the GPU’s? Or is their some optimization that I’ve missed?
Thanks in advance. Here’s the hardware set-up. I plan to add a Kramer 6×6 matrix switcher at some point, but wanted to get this working first.
Hardware:
Mac Pro, 333GHz 6-core, OS 10.6.4
GPU1 ATI *5770 ->miniDP-to-Dual-linkDVI-> control+Panasonic Projectors 1-2
GPU1 ATI 5870 ->miniDP-to-Dual-linkDVI-> Panasonic Projectors 3-5

*We hope to add another 5870 if we can figure out how to power it externally

Christopher

Patch

– Pasted Max Patch, click to expand. –

January 6, 2011 | 5:14 am

Maybe I’m just not seeing it…but it seems like all 5 outputs are showing the exact same thing? There must be a better hardware solution for something like that. You could even just get two matrox triplehead2go’s and panel the window a few times in the same gl render context. Also..don’t most projectors have a monitor out connection..they could just be daisy chained together.

Projectors don’t have "shaders" but theyre not really upsampling the resolution either. The size of the final window really shouldn’t matter..but one thing you can do is check your shader or gl context’s ‘dest_dim’ when you option click the slab’s inlet it will give you a list of all it’s attributes..it will also be in the inspector.

You seem to have most of the framerate saving measures in place so I don’t have a lot of suggestions for you. It’s probably the 5 render contexts that is killing you…there are more efficient ways to tile the same image but right now, even with your powerful computer im not sure if its using each graphics card like you’re hoping. Try making a super wide image and moving each individual frame with a rota slab instead.

Not sure why you’re sending your windows to exact destinations in the other monitors..why not just fullscreen them and have jit.displays assign them to each window..but that may be what you’re doing..hard to tell without being hooked into 5 monitors


January 6, 2011 | 10:59 am

-"Sources will vary, so for now I’m just using jit.qt.grab @640 480"… I have a Matrix Switcher if all I want to do is copy five images. I’m just using the above to test the system.

-Sorry, I said "shaders" when I meant "scalers". If you send them an SD image they have to upscale that image to their native resolution (1920 x 1080). But it seems my graphics cards, rather than they, are doing to scaling. That’s what I want to change.

-I’ll try fewer contexts.

-I don’t understand "The size of the final window really shouldn’t matter.." then why does my frame rate plummet when I go Full-screen?

-"Not sure why you’re sending your windows to exact destinations in the other monitors..why not just fullscreen them and have jit.displays assign them to each window." That’s what I’m doing but BEFORE I go full-screen and/or start redering. Otherwise they will go full-screen on my monitor, and on the same GPU, and then be sent to the projector coordinates.

Thanks though.

Christopher


January 6, 2011 | 2:42 pm

"-I don’t understand "The size of the final window really shouldn’t matter.." then why does my frame rate plummet when I go Full-screen? "

Hah..well this is my question too…I don’t think it’s ever happened to me. One thing to compare when you’re in full screen is the texture size of your shaders and such..to make sure theyre staying right where you think they are

If you check the ‘dim’ attribute of your slab and videoplane when you start up the patch you’ll see they’re sort of arbitrary default values.. 20×20 for videoplane (1×1 dest_dim) and 256x 256 for the slab texture.

Then when you start up the patch, the slab goes to 640×480, and the dest_dim of videoplane is 320×240…maybe try locking the dest_dim attribute of the videoplanes to 640×480? Just to make sure it’s staying put


January 6, 2011 | 9:17 pm

i would first set the display size using the OS (this should be dependent upon which resolutions the projectors support). so if you want your output to display at 800×600, set the projectors to this resolution (using Display preferences on Mac, or gpu software on windows).

i would then use the rect attribute to to jit.window, and not the fullscreen attribute. set this once before rendering starts, and don’t change it. set it to the exact size of your display.

as mentioned, all displays from the same GPU (even if it’s different outputs/ports on the same GPU) can and probably should use the same context. so if your two displays from the same GPU are 800×600, you should create a single context with @rect 0 0 1600 600.

if you’re still getting crappy framerate, try toggling the border or fsaa or floating attributes on the jit.window, after rendering starts. this causes the context to be rebuilt with the exact dimensions it needs, and may fix fps problems (but shouldn’t be necessary if above directions are followed).

MAKE SURE you are not spanning a single window across multiple GPU’s (even a single pixel width will cause extreme fps problems).


January 7, 2011 | 4:33 am

+1 to use the rect attribute, I have noticed many fps problems when going fullscreen, but using a rect attribute (and no border) that’s the same size as fullscreen never seems to give problems. In fact, sometimes when toggling fullscreen the fps drops and stays low, even after going back to tiny windows; even working in the patch itself gets clunky. Only restarting Max fixes this. Though my OpenGL version isn’t up to date, so that might be the issue, will check it out.

Sounds like an ambitious project, hope you get it working up to par!


January 7, 2011 | 4:50 pm

Gentlemen,

Thanks SO much!

Using OSX to set the output resolution going to the projectors definitely shifted the scaling to the projectors. The patch above ran at 20 fps with fullscreen mode on or off.

Using two contexts instead of five, and using the ‘rect’ attribute brought the frame rate up to a health 24 fps, even with some discrete processing for each screen…I’m a very happy camper. Out of curiosity though, I did hit the full-screen toggle after setting this up, and the output jumped from 5 windows into 2 (one output for each GPU) and the frame rate dropped by half. So your advise to use ‘rect’ rather than fullscreen was spot on!

Thanks again. I would have NEVER figured this out by myself.

Christopher


March 28, 2011 | 10:51 am

Hi Christopher!
Can i ask how many outputs your GPUs had? Did you use any Matrox boxes or something similar?


Viewing 8 posts - 1 through 8 (of 8 total)