[Paraview] Data Server / Rendering Server Split
Arash Jahangir
arash at vije.ca
Thu, 25 Mar 2004 10:11:49 -0500
This is a multi-part message in MIME format.
------=_NextPart_000_00FD_01C41251.961EAC20
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Several years ago we used a package to "replace" X-Windows so that we =
could access remote servers over the internet quickly (those were the =
pre-broadband days). I can't remember the name of the package (Go =
Graphics?) but their approach was quite neat and perhaps of help to this =
project.
Instead of implementing the X client/server, they simply ran everything =
on the remote server and used the Ethernet as a very long KVM cable. =
This is to say there was no communication between the client and the =
server except for a set of mouse and keyboard movements sent from the =
workstation to the server and a set of "video" signals encapsulated =
within the IP packets back to the workstation.
Not only this approach had very low overhead, it also removed many of =
the compatibility issues across platforms as it really did not matter =
what windowing system (or hardware) the server was running.
hth,
Arash
> From: James Ahrens <ahrens at lanl.gov>
> Date: Wed, 24 Mar 2004 16:49:32 -0700
> To: paraview at paraview.org
> Subject: [Paraview] Data Server / Rendering Server Split
>=20
> LANL and Kitware are working on a mode for ParaView in which there =
will=20
> be a visualization/data server (that will run on the supercomputer=20
> where the simulation data is created and stored), a rendering server =
(a=20
> visualization machine/cluster and/or tiled display) and a client (the=20
> current client GUI). This will eliminate the need for data movement=20
> from the supercomputer where the data is created and stored to a=20
> visualization resource. The visualization/data server will create=20
> geometry, this geometry will be sent to the rendering server and GUI=20
> for display. Brian and Joel, I think this will solve the problem Joel=20
> was experiencing in terms of "getting the polygons to the graphics=20
> cards". An initial prototype should be available soon (on the order =
of=20
> month or two).
>=20
> --Jim
>=20
------=_NextPart_000_00FD_01C41251.961EAC20
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Several years ago we used =
a package to=20
"replace" X-Windows so that we could access remote servers over the =
internet=20
quickly (those were the pre-broadband days). I can't remember the =
name of=20
the package (Go Graphics?) but their approach was quite neat and perhaps =
of help=20
to this project.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Instead of implementing the X =
client/server, they=20
simply ran everything on the remote server and used the Ethernet as a =
very long=20
KVM cable. This is to say there was no communication between the =
client=20
and the server except for a set of mouse and keyboard movements sent =
from the=20
workstation to the server and a set of "video" signals encapsulated =
within the=20
IP packets back to the workstation.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Not only this approach had very low =
overhead, it=20
also removed many of the compatibility issues across platforms as it =
really did=20
not matter what windowing system (or hardware) the server was=20
running.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>hth,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Arash</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT> </DIV>
<DIV>> From: James Ahrens <<A=20
href=3D"mailto:ahrens at lanl.gov">ahrens at lanl.gov</A>><BR>> Date: =
Wed, 24 Mar=20
2004 16:49:32 -0700<BR>> To: <A=20
href=3D"mailto:paraview at paraview.org">paraview at paraview.org</A><BR>> =
Subject:=20
[Paraview] Data Server / Rendering Server Split<BR>> <BR>> LANL =
and=20
Kitware are working on a mode for ParaView in which there will <BR>> =
be a=20
visualization/data server (that will run on the supercomputer <BR>> =
where the=20
simulation data is created and stored), a rendering server (a <BR>>=20
visualization machine/cluster and/or tiled display) and a client (the =
<BR>>=20
current client GUI). This will eliminate the need for data movement =
<BR>>=20
from the supercomputer where the data is created and stored to a =
<BR>>=20
visualization resource. The visualization/data server will create =
<BR>>=20
geometry, this geometry will be sent to the rendering server and GUI =
<BR>>=20
for display. Brian and Joel, I think this will solve the problem Joel =
<BR>>=20
was experiencing in terms of "getting the polygons to the graphics =
<BR>>=20
cards". An initial prototype should be available soon (on the =
order of=20
<BR>> month or two).<BR>> <BR>> --Jim<BR>> =
<BR></DIV></BODY></HTML>
------=_NextPart_000_00FD_01C41251.961EAC20--