Hi Robert, Linux, of course :) Suse 10.1 64-bit, to be specific. We were planning on doing two machines each generating 3840x1024, but when we saw the performance with 3 screens, we couldn't resist trying it with 6. I'm quite impressed with the card, it's generating 6 screens and under full load it's holding at 60C.
It was much easier than expected: - Enable the TwinView in X11 - Set the MetaModes to "3840x1024,3840x1024" - Set TwinViewOrientation to "Above" Ken. On Mon, 2006-10-23 at 21:11 +0100, Robert Osfield wrote: > Hi Ken, > > 3840x2048 with two TripleHead2Go's... so how did you set it up? > Windows, Linux, OSX? > > I've done 3840x1024 with my TripleHead2Go under linux, but hadn't > considered the possibility that one might be able to stack them like > you have. > > Robert. > > > On 10/23/06, Ken Sewell <[EMAIL PROTECTED]> wrote: > > > > For large multi-screen setups, we've had success with matrox's > > triplehead2go product. We are running a setup that has a dual core > > machine with one 7900GTX and two TripleHead2Go boxes. As far as OSG is > > concerned its only rendering one 3840x2048 window with one camera on one > > rendersurface, which in reality is spread across 6 screens. We are > > rendering a large PagedLOD database with 0.3m imagery, and it stays > > at/above 60fps. Just another option for you to consider. > > > > Ken. > > > > http://www.matrox.com/graphics/en/gxm/products/th2go/home.php > > > > On Mon, 2006-10-23 at 20:06 +0100, Robert Osfield wrote: > > > Hi Yefei, > > > > > > The best way to do three outputs from two cards is to have two render > > > surfaces, one per car, then have two camera/viewports sharing one > > > render surface on one card, and one camera/viewport on the other card. > > > > > > Robert. > > > > > > On 10/23/06, Yefei He <[EMAIL PROTECTED]> wrote: > > > > I use two GeForce 7950GX2 cards to drive three displays, running on > > > > Windows XP. Each card has two GPUs. It is able to render at 60Hz in > > > > a lot of situations. So it seems to be a single GPU, multi- > > > > rendersurface issue, not a single card, multi-rendersurface issue. > > > > I do notice some performance related issues though. > > > > > > > > 1. Rendering three channels is slower than rendering one or two > > > > channels (obviously). For one ive file I tested, I only got 30Hz > > > > when rendering three channels, but got 60Hz by rendering two > > > > channels, either one channel per card or even two channels driven by > > > > the same card. The antialiazing was set at 4x. When I dropped it to > > > > 2xQ, it was able to reach 60Hz with three channels. Limits in the > > > > throughput of the rendering pipeline? > > > > > > > > 2. What is the deal with cessna.osg? It takes over 10ms in the draw > > > > stage. dumptruck, cow, etc. all take less than half a ms. Dumptruck > > > > actually has a much higher triangle count. Needless to say, multi- > > > > channel configuration suffers when rendering cessna, as it takes > > > > over 10ms on each of the channels to draw after parts of the plane > > > > appear in all three channels. > > > > > > > > Yefei > > > > > > > > > > > > > > Date: Tue, 17 Oct 2006 09:00:49 -0700 > > > > > From: "Don Burns" <[EMAIL PROTECTED]> > > > > > Subject: Re: [osg-users] Multi-window performance > > > > > To: "osg users" <[email protected]> > > > > > Message-ID: > > > > > <[EMAIL PROTECTED]> > > > > > Content-Type: text/plain; charset="utf-8" > > > > > > > > > > The issue is two windows on one card, single threaded. This > > > > > should _not_ cause the performance to drop to 30 hz., but it > > > > > does... and probably because two swapBuffers are being issued > > > > > in the same frame. Since the driver is causing swapbuffers > > > > > to block, one swap has to wait for the next, causing the > > > > > frame rate to split in half. > > > > > > > > > > This also limits what we can do on the CPU to manage > > > > > threads/graphics contexts and frame rate, not to mention > > > > > keeping of statistics. > > > > > > > > > > I'd really like to get NVIdia to drop the blocking of the CPU > > > > > in the swapbuffers call, at least as an option for > > > > > applications that want to have better control in the CPU. > > > > > > > > > > -don > > > > > > > > > > > > > _______________________________________________ > > > > osg-users mailing list > > > > [email protected] > > > > http://openscenegraph.net/mailman/listinfo/osg-users > > > > http://www.openscenegraph.org/ > > > > > > > _______________________________________________ > > > osg-users mailing list > > > [email protected] > > > http://openscenegraph.net/mailman/listinfo/osg-users > > > http://www.openscenegraph.org/ > > _______________________________________________ > > osg-users mailing list > > [email protected] > > http://openscenegraph.net/mailman/listinfo/osg-users > > http://www.openscenegraph.org/ > > > _______________________________________________ > osg-users mailing list > [email protected] > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
