[rescue] A productive weekend...

[Joshua Boyd]

On Mon, Jan 19, 2004 at 02:52:38PM -0500, Matthew Haas wrote:

>  MCO? (Multi-channel operation?) Not familiar with it, or maybe just not
> with the acronym.

Multi Channel option.  It hooked on the RE2 boardset and let you drive 6
displays per RE2.

I know that IR can let you do something similar somehow.  Just not
really sure how.  I think the IR can just drive a few displays directly,
but I forget how many.  After that, you need more IR pipes, which would
be problematic, I would imagine.
 
>  We would like to have an SGI-driven wall, so it would be nice if it could
> be rigged up. I've found the biggest problem is that the machines often
> don't like to cooperating due to "special" X extensions being loaded, or
> special libraries not as accessible or compatible on different
> architectures. Using our existing setup (using dmx to overlay a big X
> server- see Mark's e-mail that he just posted), I tried having our G5
> drive the wall, but Apple's X proved (at least from our initial tests) to
> use incompatible extensions so the visuals were incompatible.

Interesting.  I pipe OpenGL displays quite a bit between my Linux
machine (Geforce3, nvidia drivers) and my Octane.

However, the applications I usually pipe are unlikely to use anything
that isn't in the OpenGL 1.2 spec.

> >  I mention it
> > because I kinda got the impression that you were trying to drive a lot
> > of displays from one machine (since you mention 15FPS using mplayer on a
> > P4).  Ahh, here we go.
> >
> 
>  Right now that is the easiest way to have gotten enough of a demo
> together to please the crowds. Our main goal is in distributed systems
> research, so ultimately we'd like to come up with other methods where the
> processing is allocated amongst the machines, and each machine controlling
> its own display in synchonization with the others. But this would then
> require a need for custom-applications, which is all part of the game in
> the long run.

If you try to distribute the processing and the displaying equalling
(each machine does the processing for it's display, and nothing else)
you will likely find that your machines are running a severely
unbalanced load.  So far, no one has found a universal way to deal with
this for all types of rendering.  The best I've seen is two have two
distributed applications.  One application splits up the main
computation evenly among all the machines, and pipes it's information to
the second application, which displays it on all the machines.

BTW, I saw this used for volumetric rendering once.  All the machines
rendered part of a volume, then the images were split up and sent back
for display.  In this particular case, it was one machine driving the
display, with a rendering cluster behind it, but it probably would be
fairly trivial to have a display cluster. 

I can did up a reference if you like, though I haven't really seen much
evidence of you doing volumetrics, so I suspect you may not care.
 
>  But like any new topic, it takes some time to play and figure out how to
> rig up such things.
> 
> > WireGL(http://www.graphics.stanford.edu/software/wiregl/index.html) and
> > the Chromium project (http://chromium.sourceforge.net/).
> >
> 
>  These sound very interesting, and may be well worth some deep exploration
> in a directed study I am doing this semester in distributed visualization.
> 
> > You must have a lot of fun.  I somewhat envy you.
> >
> 
>  We try and have a good time. We're somewhat of a rogue group, although
> we've been managing to please the "upper management" for a while, the
> general "Computer Science" crowd thinks we would better spend our time if
> we calculated run-times and big-Oh notation.