linuxconsole-dev

AW: AW: AW: Creating a planetarium using Ruby

[Unger R. <ric...@te...>]

=20

> -----Urspr=FCngliche Nachricht-----
> Von: Helge Hafting [mailto:hel...@ai...]=20
> Gesendet: Donnerstag, 16. M=E4rz 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 / =
screen=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.

Yeah, finding those cards might be tricky... I'm not aware of any GFX =
Cards 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
> 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

Here the problem is that you would have to "split" your MPEG across =
multiple screens - that does not seem like a trivial task to me. If you =
started with a single MPEG file, you would have to calculate which parts =
of the image fall on which screen, split the parts, scale and distort =
each part appropriately, recode the parts into seperate MPEG streams and =
then send them to the different MPEG devices... ugh.

> >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

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 =
screen boundaries. (Isn't that what they call "Genlock"?) This requires =
some kind of synchronization signal for the screens and GFX cards...

Richie

>=20
> Helge Hafting
>=20

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

[Helge H. <hel...@ai...>]

Unger Richard wrote:

>Here the problem is that you would have to "split" your MPEG across multiple screens - that does not seem like a trivial task to me. If you started with a single MPEG file, you would have to calculate which parts of the image fall on which screen, split the parts, scale and distort each part appropriately, recode the parts into seperate MPEG streams and then send them to the different MPEG devices... ugh.
>  
>
I was considering one mpeg per screen.  Splitting a single one up is
useless even if you can do it - the loss of resolution means
no need for 20 screens.

>>No guarantee that one gets near the theoretical limit. :-/ 
>>The synchronization should be simple, just take care to 
>>update the screens in sequence.
>>
>>    
>>
>
>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 screen boundaries. (Isn't that what they call "Genlock"?) This requires some kind of synchronization signal for the screens and GFX cards...
>  
>
You're right.  It could be a problem if there is lots of such movement from
one frame to the next.

Helge Hafting

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...>