Quad Processor Performance Issue
I am working on an installation that my collaborators and I have managed to snag a quad G5 for. We thought this would be the answer to all of our problems but, as you can guess, it wasn’t.
With a named matrix and dstdims we are making a grid of 16 videos (just like the 16jNamedMatrices.pat tutorial but with 16 videos instead of two and 720×480 instead of 320×240).
The problem we are having is that Jitter seems to use only one processor and totally max it out. I tried all the parallel/parallelthreads/parallelthresh stuff, but it didn’t seem to make any difference.
At first I thought it was a bottleneck problem (the computer has to read 16 videos off the same drive)but, when I opened the same patch simultaniously with runtime, it used a new processor and both patches ran with the same framerate, maxing out there individual processor.
Obviously, what I would like to do is spread the processing between all four processors, but I can’t figure out how to do this.
On Feb 13, 2006, at 8:20 AM, Aaron Miller wrote:
> The problem we are having is that Jitter seems to use only one
> processor and totally max it out. I tried all the parallel/
> parallelthreads/parallelthresh stuff, but it didn’t seem to make
> any difference.
This depends largely on the operation. Mostly the only things which
are parallelized are point wise operators that do things like jit.op,
jit.clip, jit.charmap, jit.chromakey, etc. (i.e. not spatial
operators like jit.rota or the srcdim/dstdim jit.matrix copying), and
even then it is only parallelized within a single object, rather than
parallelizing different graphs of objects.
> At first I thought it was a bottleneck problem (the computer has to
> read 16 videos off the same drive)but, when I opened the same patch
> simultaniously with runtime, it used a new processor and both
> patches ran with the same framerate, maxing out there individual
> Obviously, what I would like to do is spread the processing between
> all four processors, but I can’t figure out how to do this.
Note that you can run 4 instances of Max simultaneously (just need to
give the application 4 different names) and transfer jit.matrices
between them with jit.net.send/receive pairs. This will let you make
use of multi-processors for each process.
I might also suggest you use textured geometry to cut up your video
on the GPU, which will probably be faster if you don’t need to
perform additional CPU base processing on the slices.
Lastly, if you know you are going to be splitting the videos, you
might as well cut up the video in advance, performing non-realtime
processing, wherever processing doesn’t need to happen in real time,
Some more points.
As Joshua already mentioned, use the GPU. The biggest advantage of a
quad is that is had the 16 lanes to and from! the pci GPU.
You could also try to build it in opengl and use videoplanes.
You could also try loading your videos in the ram using loadram, if
you don’t have to switch video’s
You could also try using uyvy colormode to make the matrices smaller
in the patch. Remember to put all the available stuff in uyvy mode, or
else you will have a greenish screen.
That are my suggestions to generally speed up the patch.
And now I will put my tipsy head to bed :)
Forums > Jitter