I am having my first (yeeeey:) AV performance next week and I would like to get the best out of my equipment. I will be using 1 projector and 1 screen (screen will be my interface). So I was thinking if it is possible, to split the work between two graphic cards. The stronger graphic card would take the openGL processing part and the "projector display" while the weaker graphic card would be displaying my screen/monitor.

I already tried that, one graphic card for each display, but the problem is that the openGL processing part falls on the weaker graphic card. Are there any settings or objects where I could define such things?

PS: I am using 3 years old mac pro with its default graphic card (some weak NVIDIA) and ATI Radeon HD 5770 as the "strong" graphic card.

I am having my first (yeeeey:) AV performance next week and I would like to get the best out of my equipment. I will be using 1 projector and 1 screen (screen will be my interface). So I was thinking if it is possible, to split the work between two graphic cards. The stronger graphic card would take the openGL processing part and the "projector display" while the weaker graphic card would be displaying my screen/monitor. 

PS: I am using 3 years old mac pro with its default graphic card (some weak NVIDIA) and ATI Radeon HD 5770 as the "strong" graphic card.


2-graphic-cards-for-jitter-performance

have you tried simply removing the default card or disabling it? The ATI on its own should be plenty powerful for most applications.

using two separate graphics cards (as opposed to two display ports on the same GPU) will require you to create and manage two distinct render contexts. these contexts also cannot be shared, without causing a drop in FPS.

so if your intention is to create a preview monitor that mirrors your main display, you are probably better off using a single GPU.

The ATI on its own does the job very well, but only to some extend. When I enable too much processing at the same time i get a lot of frame dropping.

What I am doing is sonographical spectral processing - the idea is stolen from Luke Dubois's patch pvoc_3D. I developed the whole thing much further, added many of Francois Charles's improvements and also around 40 new spectral effects (I will very soon share my dissertation and patches concerning that subjetct). The whole phase vocoder/graphical synth is implemented very economical, if some effect is turned off, the matrix passes all the objects etc. So my problem is that I am working with very large matrices due to the FFT parameters I am using (4096 frames at overlap 8, resulting in around 400x2048 matrices for only few seconds of sound. At the top of the 3D model (spectrogram) I also have a texture (2D spectrogram + reading/scanning line from jit.lcd)... So at the end I am displaying downsampled matrix as a mesh (400x512 vertices) and a huge texture over the top (2000x300). I need to have a big texture in X direction to guarantee the smooth movement of scanning line. And please, don't ask me why 300:)

So on my monitor, I have the projected content displayed in a very small jit.pwindow. The video content comes into it as a matrix. So there is no need for an openGL rendering context on my monitor. I need only my commands and that small jit.pwindow.

My whole chain looks something like this:

audio-->FFT data in matrix-->openGL (spectral processing pt.1)-->back to CPU((spectral processing pt.2)--->and back to openGL for 3D rendering.

Only the last part of openGL will be displayed on the projector. The first GL part is not visible, although the effect is of course seen at the end.

So is there any chance that all the openGL could be covered by ATI?

Only the last part of openGL will be displayed on the projector. The first GL part is not visible, although the effect is of course seen at the end. 

using two gpus means two render contexts . as mentioned above.

why dont you use a vga amplifier with two outputs one for the projector and one for a preview screen .

and use the second output on the ati 5770 for a simple gui. that would do fine

using two gpus means two render contexts . as mentioned above.
why dont you use a vga amplifier with two outputs one for the projector and one for a preview screen .

and use the second output on the ati 5770 for a simple gui. that would do fine


"using two gpus means two render contexts . as mentioned above."

OK, it seems that I am missing something here. What I don't understand is: if 2 GPUs mean 2 render contexts, then 1 GPU mean 1 render context and no render context mean no GPU. But, I obviously need a graphic card to display my simple GUI, or this forum, or anything visible on my monitor... Is there any render context present when I don't use openGL? Like in simple gui?

I am very new to this world so I am still very confused...

OK, it seems that I am missing something here. What I don't understand is: if 2 GPUs mean 2 render contexts, then 1 GPU mean 1 render context and no render context mean no GPU. But, I obviously need a graphic card to display my simple GUI, or this forum, or anything visible on my monitor... Is there any render context present when I don't use openGL? Like in simple gui? 

I am very new to this world so I am still very confused...


If you know someone else with an ATI 5770 or if you have the money, you can put two 5770s in Crossfire mode so that they work together as one single card.

Or, if you have a laptop, you can split the GUI part and the openGL-processing+output part and have the GUI on the laptop control the heavy stuff on the Mac pro over ethernet.

"If you know someone else with an ATI 5770 or if you have the money, you can put two 5770s in Crossfire mode so that they work together as one single card."

I was reading in some older topics that Jitter does not handle well with crossfire. Is this still true in Max 6? Because I could get another 5770...

"Or, if you have a laptop, you can split the GUI part and the openGL-processing+output part and have the GUI on the laptop control the heavy stuff on the Mac pro over ethernet."

That is a great idea! I am just afraid that I won't have time for that...because my GUI, as a whole, is actually massive. The main GUI window is small, but then I have around 50 subpatchers in presentation modes that can be popped out via thispather.

Thanks a lot for all the help so far! Very grateful!

That is a great idea! I am just afraid that I won't have time for that...because my GUI, as a whole, is actually massive. The main GUI window is small, but then I have around 50 subpatchers in presentation modes that can be popped out via thispather. 

Thanks a lot for all the help so far! Very grateful!


" but the problem is that the openGL processing part falls on the weaker graphic card."

the opengl processing part will take place on the gpu which shows the jit.window who is linked to the jit.gl.render

the actual jit.gl.render object could be in a patch on the 'weaker' gpu .

important to first move the jit.window to the other gpu and then start the metro .

but i would skip the nvidia card and just doit all with the ati .

important to first move the jit.window to the other gpu and then start the metro . 

I have overdrive turned OFF. AFAIK, overdrive should be off when working with Jitter (so it says in Max documentation). Although I would prefer to have it on actually...to deprioritize some GUI events. I'll also try turning the overdrive ON and placing deferlow object here and there...

http://forums.macnn.com/77/gaming/436443/crossfire-sli-os-x-why-not/

is crossfire supported at all on OSX? http://forums.macnn.com/77/gaming/436443/crossfire-sli-os-x-why-not/


My best guess, is due to Apples unified driver architecture used in Mac OS X for GPUs. Basically, vendors like Intel, ATI and NVidia conform to Apples drivers setup and shim into it where needed. This is why, for the most part, things just work. This is also why, for the most part, things *tend* to be slower on Mac OS X vs booting the same system in Windows. Windows drivers (last I looked this up and checked) pretty much control the whole stack, which means optimizations, special options like cross fire and SLI, but also 8 billion driver revisions, special software control panels and a confusing ecosystem of software/hardware incompatibilities and gotchas.

Apple opts for the unified approach. This doesn't mean SLI or cross-fire is not possible, it just means Apple would most likely have to add hooks in the driver achritecture and abstract all of this stuff in a way that is more or less compatible with existing implementations. Then ATI and Nvidia can add support in the Mac end of the drivers.

That said, all of the above is circumstantial at best. Most of my understand of the internals comes from off-list discussions with ATI and NVidia engineers about Mac OpenGL gotchas. Take that with a grain of salt.

Why don't you just split the signal with an hdmi or vga splitter and run it to its own monitor. You could focus the optimization of your program even more for the best output possible, and also be able to monitor it more clearly. This will also be around the same cost as another graphics card.

Maybe I'm missing something, but it appears to me that you just want to have the patch gui on one screen with only matrix data directly to a [jit.pwindow] and then the opengl output (in a single [jit.window]) on the other. In which case, you don't need 2 contexts or anything like that. You just need to have the [jit.window] on the correct screen before you bang the [jit.gl.render] that draws to it. Then it should build the context on the right GPU and play nice and smoothly :)

"Maybe I'm missing something, but it appears to me that you just want to have the patch gui on one screen with only matrix data directly to a [jit.pwindow] and then the opengl output (in a single [jit.window]) on the other. In which case, you don't need 2 contexts or anything like that. You just need to have the [jit.window] on the correct screen before you bang the [jit.gl.render] that draws to it. Then it should build the context on the right GPU and play nice and smoothly :)"

That is exactly my situation and plan A for today. Thanks to everybody for such a great help and many additional explanations/knowledge! I'll report back as soon as I get to the machine...thanks!

PS: Concerning that Mac-Windows debate... I tried my patch also on Windows machine. But the picture was flickering at full screen (not if I manually re-sized it) and the motionblur (caused by using opaque erase color in jit.g.render) was leaving traces...?

quote:
"Maybe I'm missing something, but it appears to me that you just want to have the patch gui on one screen with only matrix data directly to a [jit.pwindow] and then the opengl output (in a single [jit.window]) on the other. In which case, you don't need 2 contexts or anything like that. You just need to have the [jit.window] on the correct screen before you bang the [jit.gl.render] that draws to it. Then it should build the context on the right GPU and play nice and smoothly :)"

PS: Concerning that Mac-Windows debate... I tried my patch also on Windows machine. But the picture was flickering at full screen (not if I manually re-sized it) and the motionblur (caused by using opaque erase color in jit.g.render) was leaving traces...?


will work fine as long as you don't want a preview on the gui screen. then shared contexts and/or readback come into play.

thanks to your advices i managed to split the work as i wanted between two graphic cards. but from some unknown reason, the performance was better on single one. unfortunately i don't have time right now to investigate further...

and yes, on my GUI screen I have only 2D spectrogram preview in my jit.pwin which comes into it as a matrix. the other screen displays 3D spectrogram and has its own rendering context

according to lack of time and the fact, that performance will happen in few days, i will stick to 1 GPU. but thanks a lot for all your help! i will definitely investigate further in near future...

2 graphic cards for Jitter performance?