ACESgrid Hyperwall Reference Material
We are experimenting with setting up a hyperwall for the ACES project. The hyperwall contains an array of flat panel monitors that can be used to display large images split over a matrix of screens or to display multiple related images in a matrix. To display images on the hyperwall we use cool software from Chris Henze at NASA AMES. You can find out more about Chris's Hyperwall work here. This page describes how to
-
configuring the host machines for the hyperwall for Fedora Core 1 and Fedora Core 2.
-
compile the hyperwall software on Fedora Core 2 or Fedora Core 1
-
use the hyperwall to display a big image
The introduction section below provides a brief technical introduction to the hyperwall system.
Basic setup
The hyperwall consists of a matrix of LCD panels. Images are displayed on the LCD panels by a set of rendering machines. A single controller machine is used to steer all or some subset of the rendering machines. All the machines run X Windows on top of Linux. Two main pieces of software are used. One is a program to compute or display images on each of the rendering machines the other is a program to direct mouse and keyboard events from the controller machine to some or all of the rendering machines. This allows the rendering machines to be controlled in blocks from a single keyboard. Additional small helper script programs are also used. These automate the steps involved in using the hyperwall such as staring up a program to display an image of each of the rendering machines.The hyperwall can be used to display and pan and zoom around a single very large image spread over the entire wall of displays. This allows images that are many thousamds of pixels across to be viewed at their native level of detail. However, the hyperwall system also allows sets of related images to be viewed simultaneously. This allows the visual identification of correlations between different images.
System requirements
To create a basic hyperwall setup the following hardware and software pieces are needed
-
Hardware
-
a controller machine with a monitor
-
a set of rendering machines
-
LCD panels driven from the rendering machines and arrayed in a matrix.
-
a network connecting all the systems together
-
keyboard and mouse for the controller machine
Software
-
Linux
-
X Windows
-
OpenGL extensions for X on the rendering machines
-
Software to display images on the rendering machines. There are many possible programs that can be run on the hyperwall rendering machines. The program we describe here is one example. It displays an image over all the panels of the hyperwall and pans and zooms around in response to keyboard and mouse commands.
-
Software to direct the rendering machines from the single controller.
Test images
OS configuration steps
-
This section describes what software configuration settings we applied to get machines ready for using with the hyperwall software. There are two sub-sections of configurations settings. The first sub-section has settings for Fedora Core 2 (FC2). It describes the settings we used when we were learning about the hyperwall software with a small two x two system. The second sub-section has settings we applied to Fedora Core 1 (FC1). These are the setting we used for our larger four x four system that is running on Dell 1750 nodes. The settings are very similar, however there are changes in the X windows setup between FC1 and FC2 that means that the two sets of configuration settings are not identical.
Fedroa Core 2 configuration of hyperwall nodes
-
Hardware
-
-
for this installation we used
-
-
Pentium 4 machines with the ASUS P4P800 motherboards.
-
nVdia GeForce based graphics cards that support OpenGL 1.4.
-
Samsung Syncmaster LCD panels
-
a small five port network hub
-
-
-
Setup steps
-
-
install the kernel sources - we use Fedora core 2 and select the "everything" install option. Note - we bought a couple of ASUS P4P800-E motherboards for this project only to discover that Fedora Core 2 has an install problem with these boards. In case you make the same mistake Redhat has a fix for this that can be found here https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121819#c122.
-
following installtion of the base OS the following steps are needed on the rendering machines. These steps can also be performed on the controller machine but they are not needed for that machine.
-
-
switch off firewall options ( turn off iptables service ). Note - this allows access on any port which is insecure. For a system that might get hacked it would be better to modify iptables to allow port 6000 (X) access but to still filter all the other things it does. We are keeping our system off the net for now so this is not an issue.
-
modify the gdm configuration that controls X to allow TCP connections. To do this edit the line in /etc/X11/gdm/gdm.conf that reads
#DisallowTCP=TRUE
to instead readDisallowTCP=FALSE
-
set X server to support OpenGL. To do this install the nVidia driver and then modify the Section "Device" part of /etc/X11/xorg.conf to read:
Section "Device" Identifier "Videocard0" Driver "nvidia" VendorName "Videocard vendor" BoardName "NVIDIA GeForce FX (generic)" Option "RenderAccel" "On" Option "IgnoreDisplayDevices" "DFP,TV" Option "ConnectedMonitor" "CRT" Option "HWCursor" "On" EndSection
This requires the nvidia X server. The revision we used is 1.0-5336. The nvidia web site has the latest version of their X server for Linux.
-
-
-
reboot
-
check that you can access the rendering machines X server via TCP. When X server access is working the command
telnet localhost 6000
issued on a rendering machine, should return the promptEscape character is '^]'.
and nottelnet: Unable to connect to remote host: Connection refused
Fedroa Core 1 configuration of hyperwall nodes
-
Hardware
-
-
this test system has sixteen Pentium 4 Xeon DELL 1750 machines as rendering machines. These machines are compute nodes within a larger cluster. The installation differs from our Fedora Core 2 setup described above because our cluster machines do not have GNOME, KDE etc...
-
we use PCI nVdia GeForce based graphics cards that support OpenGL 1.4. This requires risers in the 1750 that support PCI cards. The risers that came in our systems had dual PCI-X slots. We had to contact Dell to get 1 PCI/1 PCI-X risers instead.
-
we use Samsung Syncmaster LCD panels
-
-
Our setup steps
-
-
install the kernel sources - we use Fedora core 1 and select the basic install options without GNOME or KDE.
-
following installtion of the base OS
-
-
switch off firewall options ( turn off iptables service ). Note - this allows access on any port which is insecure. For a system that might get hacked it would be better to modify iptables to allow port 6000 (X) access but to still filter all the other things it does. Our cluster compute nodes are behing a front-end machine that ats as a firewall.
-
set X server to support OpenGL. To do this install the nVidia driver (see above) and then modify the Section "Device" part of /etc/X11/XF86Config: to read:
Section "Device" Identifier "Videocard0" Driver "nvidia" VendorName "Videocard vendor" BoardName "NVIDIA GeForce FX (generic)" Option "RenderAccel" "On" Option "IgnoreDisplayDevices" "DFP,TV" Option "ConnectedMonitor" "CRT" Option "HWCursor" "On" EndSection
-
-
-
modify the system boot and X startup so that X is started when the machine boots and that a single xterm is displayed. To do this
-
-
add the following to the file /etc/rc.d/rc.local
export PATH="/usr/X11R6/bin:$PATH" /usr/X11R6/bin/startx > /dev/null 2>&1 & export DISPLAY=":0.0" /usr/X11R6/bin/xhost +
-
create the file /root/.Xclients containing
xterm
This file needs to have its executable permission bit set.
-
-
reboot
-
check that you can access the X server via TCP. When X server access is working the command
telnet localhost 6000
should return the promptEscape character is '^]'.
and nottelnet: Unable to connect to remote host: Connection refused
Compiling the hyperwall software
- The hyperwall needs two sets of software. The program hyperX.C is used to broadcast X events from a controlling machine to a set of rendering machines. The base sources for hyperX.C can be found in utilties.tar. The programs genPaged and showPaged respectively preprocess and display .ppm images in a matrix form. The base sources for genPaged and showPaged can be found in bigView.tar.
-
Compiling hyperX.C
-
-
to compile hyperX.C with Fedora Core 2 use the command
g++296 -o hyperx hyperX.C -L/usr/X11R6/lib \ -lXp -lXm -lXt -lXext -lX11 -lXtst
this produces an executable file called hyperx. Note - in our version of hyperX.C we comment the lines = s + ":0.0";
to read//s = s + ":0.0";
this means we must specify ip-address:display_number pairs on the hyperx command line. We did this to experiment with systems that had multiple graphics cards and displays per display machine. X supports this by creating multiple displays numbered :0.0, :0.1 etc... Unfortunately driving all these displays simultaneously does not appear to be stable and machines configured this way frequently hang. So for now we have one display machine per display.
-
-
Compiling genPaged and showPaged
-
-
to compile genPaged and showPaged switch to the bigView/ directory and type
make
-
Displaying a big image over all the panels in the hyperwall
-
rendering machines have been set up according to the Fedora Core 1 steps above.
-
the controller machine has Fedora Core 2 installed. This machine has IP address 10.12.2.250.
-
the rendering machines have IP addresses 10.12.2.12 - 10.12.2.27. They are connected to the LCD panel in the following matrix
10.12.2.15(0,3) 10.12.2.19(1,3) 10.12.2.17(2,3) 10.12.2.26(3,3) 10.12.2.22(0,2) 10.12.2.21(1,2) 10.12.2.12(2,2) 10.12.2.16(3,2) 10.12.2.20(0,1) 10.12.2.25(1,1) 10.12.2.18(2,1) 10.12.2.24(3,1) 10.12.2.14(0,0) 10.12.2.23(1,0) 10.12.2.27(2,0) 10.12.2.13(3,0)
The numbers in parentheses show the coordinates in the LCD matrix that the showPaged program uses to refer to a particular LCD in the panel matrix. -
an account on all the machines is required in order to display an image.
-
converting the original image to .ppm file. The hyperwall software is written to use .ppm style image files. This means that images in other formats must be converted to .ppm files before they can be used. The command convert, found on most Linux systems, can be used to convert an image file of some other format to a .ppm format. For example issuing the command
% convert foo.jpg foo.ppm
will generate a .ppm form of the image file foo.jpg. The convert program is available on most Linux systems and can convert to .ppm from many different formats. In general using convert to create .ppm image format files seems to work well. However, for one postscript file we generated, using the GMT software package, convert did not create a .ppm file that could be processed by the genPaged program (see next step). For this file the following conversion command did work% gs -q -dNOPAUSE -dNO_PAUSE -sDEVICE=ppmraw -sOutputFile=erzican_srtm3.ppm erzican_srtm.ps
-
preprocessing to convert .ppm image to .ppm.paged format. Before an image can be displayed by showPaged it must be converted to a special form of .ppm file known as a .ppm.paged file. This conversion is performed by the genPaged program that can be found in the directory /root/Desktop/LCD/bigView on the controller machine (10.12.2.250). The input to genPaged is a .ppm file, it produces a file with the suffix .ppm.paged. The program is run with no arguments except the name of the .ppm file e.g.
% /root/Desktop/LCD/bigView/genPaged foo.ppm
the name of the file produced by genPaged is the name of the input file with the suffix .paged added e.g. foo.ppm.paged. When genPaged runs sucessfully it produces output like the text shown below.[root@localhost bigView]# ./genPaged foo.ppm ===== foo.ppm ===== Format: Binary PPM Max Pixel Value = 255 Width = 9600 Height = 7200 Components = 3[1=grey,3=rgb] Bit Depth = 8 bits Pixel Size = 3 bytes Offset = 17 bytes P6 # Paged format with mipmaps: 256x256x3 = 196608 bytes per page # Level 0 : [9600,7200] => [38,29] = 1102 pages starting at page 0 @ # 835 bytes # Level 1 : [4800,3600] => [19,15] = 285 pages starting at page 1102 @ # 216662851 bytes# Level 2 : [2400,1800] => [10, 8] = 80 pages starting at page 1387 @ # 272696131 bytes # Level 3 : [1200, 900] => [ 5, 4] = 20 pages starting at page 1467 @ # 288424771 bytes # Level 4 : [ 600, 450] => [ 3, 2] = 6 pages starting at page 1487 @ # 292356931 bytes # Level 5 : [ 300, 225] => [ 2, 1] = 2 pages starting at page 1493 @ # 293536579 bytes # Level 6 : [ 150, 112] => [ 1, 1] = 1 pages starting at page 1495 @ # 293929795 bytes # ======================================== # Total pages = 1496 # Total bytes = header + pages # = 835 + 294125568 = 294126403 9600 7200 255 Levels = 6
-
staging the file to the rendering machines. Once a .ppm.paged file has been created it should be copied to a local directory on each of the rendering machines. This ensures that I/O performance is as fast as possible. The script cppic (shown below) in the LCD/ directory on the controller machine automates this copying.
i=12 while test ! "x$i" = x28 ; do scp $1 "@10.12.2."$i":/HYPERWALL/bigView/"$1 & i=$(( $i + 1 )) done
Run this script after creating a .ppm.paged file by entering the command% ./cppic foo.ppm.paged
-
displaying the file from the rendering machines. Once a .ppm.paged file has been distributed to all the rendering machines it can be displayed by the showPaged program. The showPaged program understands the geometry of the LCD wall and controls the display of an image that is paged over the entire wall. The showPaged program executes on each of the rendering machines separately. The script showpage_all(shown below), in the directory /root/Desktop/LCD on the controlling machine can be used to start showPaged on all 16 machines with the appropriate topology. The -r4,4,n,m option is used to tell showPaged the fraction of the full matrix it is responsible for.
ssh 10.12.2.14 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,0,0 '$1 & ssh 10.12.2.23 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,1,0 '$1 & ssh 10.12.2.27 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,2,0 '$1 & ssh 10.12.2.13 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,3,0 '$1 & ssh 10.12.2.20 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,0,1 '$1 & ssh 10.12.2.25 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,1,1 '$1 & ssh 10.12.2.18 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,2,1 '$1 & ssh 10.12.2.24 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,3,1 '$1 & ssh 10.12.2.22 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,0,2 '$1 & ssh 10.12.2.21 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,1,2 '$1 & ssh 10.12.2.12 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,2,2 '$1 & ssh 10.12.2.16 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,3,2 '$1 & ssh 10.12.2.15 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,0,3 '$1 & ssh 10.12.2.19 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,1,3 '$1 & ssh 10.12.2.17 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,2,3 '$1 & ssh 10.12.2.26 'cd /HYPERWALL/bigView; export DISPLAY=":0.0"; ./showPaged -r4,4,3,3 '$1 &
Run the showpage_all on the controlling machine by entering the command./showpage_all foo.ppm.paged
-
launching the control program. Once showPaged has launched on the
./hyperx \ 10.12.2.12:0.0 \ 10.12.2.13:0.0 \ 10.12.2.14:0.0 \ 10.12.2.15:0.0 \ 10.12.2.16:0.0 \ 10.12.2.17:0.0 \ 10.12.2.18:0.0 \ 10.12.2.19:0.0 \ 10.12.2.20:0.0 \ 10.12.2.21:0.0 \ 10.12.2.22:0.0 \ 10.12.2.23:0.0 \ 10.12.2.24:0.0 \ 10.12.2.25:0.0 \ 10.12.2.26:0.0 \ 10.12.2.27:0.0
-
panning and zooming with an image displayed by showPaged. The table below shows the commands that are supported by the showPaged program. These commands cause the image that is displayed to move around and to resize.
Key or button Action right_mouse Pan middle_mouse Zoom in and out left_mouse Rotate (sphere mode only) m Toggle project onto sphere q Quit showPaged