Re: AW: AW: AW: Creating a planetarium using Ruby

[James v. Z. <ja...@dv...>]

> Yeah, finding those cards might be tricky... I'm not aware of any GFX C=
ards for 64bit PCI - they went the way of AGP...
> But I agree that it seems possible in theory. One would have to try it =
out though, and above all, identify apropriate products that provide the =
needed features.
>=20

I've a TNT2M64 floating around here somewhere that although 32-bit PCI,
is compatible with 64 bit slots and will happily clock up to 66Mhz in
such a slot.

I'm sure higher bandwidth PCI such as server PCI-X, not to be confused
with the AGP2-called-PCIX that we have in the domestic market, could
have video and mainboards found to suit. Won't be cheap.

There's a few HP servers with PCI-X 1.0 @ 133 Mhz; ML350 has at least
100Mhz, I think...

http://www.pcisig.com/specifications/pcix_20

How's 533Mhz, 64-bits wide grab you?

J

On Thu, 2006-03-16 at 10:16 +0100, Unger Richard wrote:
> =20
> > -----Urspr=C3=BCngliche Nachricht-----
> > Von: Helge Hafting [mailto:hel...@ai...]=20
> > Gesendet: Donnerstag, 16. M=C3=A4rz 2006 09:16
> > An: Unger Richard
> > Cc: lin...@li...
> > Betreff: Re: AW: AW: Creating a planetarium using Ruby
> >=20
> > Unger Richard wrote:
> >=20
> > >Hi!
> > >
> > >I don't really know, because I have not tried, but I think=20
> > the problem with smooth Animation across 20 Screens in one PC=20
> > is the bus speed.=20
> > >
> > >The PCI bus can transport 127MB / sec.
> > > =20
> > >
> > If it is a 32-bit 33MHz bus.  (133 MB/s, but some is lost to=20
> > overhead.) There are also the more expensive 64-bit 66MHz=20
> > bus, that gives you
> > 4 times as much, 533MB/s minus overhead.
> >=20
> > >Lets assume you run each screen at 1024x768, 16 bit =3D 1,5MB / scre=
en=20
> > >Now 20 Screens is 30MB of data, 127MB/30MB ~ 4, ie you could=20
> > (theoretically) drive the screens at 4 fps.
> > >
> > >That's not exactly smooth animation.
> > > =20
> > >
> > Sure not.  One could display nice very high resolution images=20
> > though. :-) But throw in a server board with two of those=20
> > 64-bit buses, and you could hit 32 fps in theory.  Well, if=20
> > you can find dual or triple screen cards for 64-bit pci that=20
> > is. Gamers might not be impressed with 32 fps, but it beats=20
> > movies at least.
>=20
> Yeah, finding those cards might be tricky... I'm not aware of any GFX C=
ards for 64bit PCI - they went the way of AGP...
> But I agree that it seems possible in theory. One would have to try it =
out though, and above all, identify apropriate products that provide the =
needed features.
>=20
> >=20
> > Some cards have mpeg decoders on them - this will allow large=20
> > bandwith savings when playing prearranged video/animations. =20
> > I am not sure mpeg for 20 screens could be generated in realtime.
> >=20
>=20
> Here the problem is that you would have to "split" your MPEG across mul=
tiple screens - that does not seem like a trivial task to me. If you star=
ted with a single MPEG file, you would have to calculate which parts of t=
he image fall on which screen, split the parts, scale and distort each pa=
rt appropriately, recode the parts into seperate MPEG streams and then se=
nd them to the different MPEG devices... ugh.
>=20
> > >Now I freely admit that calculation is simplistic. In a=20
> > modern computer some of the screens would be connected to an=20
> > AGP bus, some could be connected to PCIe. Some boards might=20
> > include more than one PCI bus, meaning the cards don't all=20
> > have to share the 127MB...
> > >
> > >Still, until I actually tried it out, I would be worried=20
> > about trying to move that amount of data (all screens more or=20
> > less in sync!) on Pc-type hardware...
> > > =20
> > >
> > No guarantee that one gets near the theoretical limit. :-/=20
> > The synchronization should be simple, just take care to=20
> > update the screens in sequence.
> >=20
>=20
> Again, I contend it is not that simple - because you would have objects=
 moving from one screen to the next, the different screens would have to =
be synchronized to prevent the objects from tearing as they crossed scree=
n boundaries. (Isn't that what they call "Genlock"?) This requires some k=
ind of synchronization signal for the screens and GFX cards...
>=20
> Richie
>=20
> >=20
> > Helge Hafting
> >=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting lang=
uage
> that extends applications into web and mobile media. Attend the live we=
bcast
> and join the prime developer group breaking into this new coding territ=
ory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=12164=
2
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
>=20
--=20
James van Zeeland <ja...@dv...>