|
|
Animation on a giant canvas - performance issues Hi there, I'm doing some tests on animating a still image across the screen. What we have is a brand new MacPro 2,4 GHz with 2xATI 5770s and one ATI 3870. The challenge is to make this work across a giant 10240x740 canvas that straddles multiple of these graphics cards. I'm testing with a simple compostion in QC where I load an image and animate it using a LFO on the X position of a billboard patch. I get only around 10 fps. Is this approach the most efficient one for my scenario, or is there anything I can do to optimize this simple animation? You know besides lowering the resolution. I really just want to know if this is the best FPS I will get. All I need is this simple left to right animation of a still image on this huge canvas. Thanx in advance for any hints or suggestions... -Vibeke
|
Interesting question on my nVidia powered iMac I can get up to 10240 * 740 pixel size.
I wonder if using a simpler approach of using an Aspect Ratio would give a better spatial size result by using say a 13:1, 512:37, something like that?
Set to Pixel Size 10240 * 740 , the far right of my viewer doesn't have a truly transparent background consistent with how QC normally checkerboards up.
See attached screen grab taken . With a simple , small still image, it really doesn't get going especially well fps wise. 2.46 fps is a plus point, with 0.96 fps at best, at present
I can well see why you might need more than one card, more than one GPU
Hi. Are you using a "render in image" patch? By default the render width and height is 0, which means that the image size is as big as your viewer (10240x740). 512x512 should be enough... Another speedup could be achieved by using multiple maschines or instances of Quartz Composer: Use the network broadcaster to send the patchtime over your local network so that all compositions are synced. There is a good broadcaster/receiver demo in your example folder.
Good luck Janni
That's a pretty cool sounding setup. How is the screen attached to the video cards? Or is it effectively 3 big screens with 3 separate inputs, and OSX is just pretending they're all one big display?
Anyway, keep in mind that no video card (that I know of at least) can render 10k pixels wide in any simple way. If it's working, it means it's doing a lot of 'magic' behind the scenes that's probably killing performance for you. Most modern cards can handle upto 4k x 4k surfaces, or possibly 8k on the newer ones?
Anyway, best way to render would probably to separate the screens if you can, so it's 3(+) smaller screens instead of one big one. Then run one fullscreen instance of the composition on each screen, and use the broadcast to sync them as Janni suggested. I'm not sure how QC will handle running separate comps on separate GPUs, and if performance in one affects the others.
Most recent machines can do 8kx8k. (holy cow, my gma950 can only do 2kx2k! lamer than expected...)
If this is a single QCRenderer or QCView, it's going to be lousy -- it'll render on a single GPU (with associated magic to get it up to 10240 pixels across?), and then read screen-sized chunks for the other displays (requiring a read from GPU to sysram back to GPU, for each display not attached to the rendering GPU). This is pretty much not going to be fast.
Separate screens (maybe QC Visualizer?) is the only way this'll work without readback per-screen. If each is rendered on their own thread (CVDisplayLink callback? not sure how those stack with multiple displays, as I've never really tried it), one that's running slow shouldn't affect the others too much (a few QC internals are shared/synchronized, like the image cache stuff, but those should be relatively infrequent compared to rendering and whatever else is going on).
Christophers explanation about the patch rendering on a single GPU then transferring chunks to the others makes total sense and explains the behaviour I'm seeing in Quartz Composer.
The task for us is to create a big sky with floating clouds and we are outputting the image via 2 Triplehead2Gos and 1 DualHead2Go onto 8 video beamers. Interesting enough my preferred tool for giant canvases Modul8 can easily handle an output of this size on this machine as long as we stick to still images that get animated in the app. But because of other limitations we are considering the possibilities in QC. Modul8 must be doing some magic somehow distributing the elements to the different gpus. I guess I would have to ask them and not you guys how that's possible.
Thanks for the suggestions, I will look into the possibilities of linking multiple compositions.
Modul8 is doing some 'magic' in the sense its been designed to handle multiple GPUs up front. Basically it is handling creating multiple Open GL rendering contexts on multiple GPUs and synchronizing all resources across them (so GPU "A" has the same textures as GPU "B"), but its 'camera' is offset so it renders a different portion of the scene. This is called tiling and makes it seem as though all of the content is from one scene, when in reality its multiple different ones, that share the same content :)
Quartz Composer editor will not the multiple GL contexts and explicit synchronization. It will however use the Mac OS X 'magic' to try and help, by rendering on one context and copying across, for you, and as Chris has said, its not as fast as the above manual synchronization.
You can try and find Quartz Composer visualizer to do something similar, but not really meant for performance/interactive stuff. I wrote a demo using multi CVDisplayLinks for rendering multiple QC Compositions on to multiple displays, with multiple compositions, and posted it to the Apple GL list. It does not handle tiling, and It was set up only for 2 displays, but in theory its something that could be extended... Hmm... That could be a nice little project.
Ah I see. Now I've been using that app (Modul8) for years without fully realizing the way it works. So it's good to hear a thorough explanation. :)