Hiperwall Inc. today announced the new version 2.0 of the Hiperwall display wall software. The new version significantly enhances functionality of existing components and adds two new ones that are very powerful. See the announcement or the Enhancements list for an overview of what is new, but I’ll mention a few of the new features/capabilities and describe why they are significant.
Security: Any connections that could connect from outside the Hiperwall LAN (such as Senders and Secondary Controllers) use authenticated SSL connections to enhance the security and integrity of the system. Sender connections even within the LAN use SSL to authenticate the connection.
Multi-Sender: The new Sender can deliver multiple portions of a computer’s screen to the display wall. This means several applications or data feeds can be shown from a single machine. Of course, the entire screen can be sent, as before. Sender performance is also improved, particularly when a Sender window is shown across a large portion of the display wall.
Secondary Controller: While the usual Control Node is very powerful and easy to use, Secondary Controllers are even more intuitive and easy to use. Secondary Controllers can be anywhere in a facility to control walls distributed throughout the area. They show a low-bandwidth view of the content on the display walls, so they can be used over wireless or at home to monitor the wall’s contents and behavior. They can also focus on a single display wall (in a multi-wall configuration) or show all active objects. You can see how easy the Secondary Controller is in the following video.
http://www.youtube.com/watch?v=h_iXg-FDjYk
Share: Until now, the Sender has been able to show applications and other data on a Hiperwall from anywhere across the Internet. With Share, Senders can be shared with several Hiperwall systems, enabling collaboration and communications across distributed sites. Share automatically adjusts the data rate based on link conditions to each display wall it connects to, so systems connected via lower speed links will not slow down the data feed to systems connected via fast links.
Streamer: The Streamer can now send what is shown on a display device, in addition the the usual capture device and movie file streaming. This is not meant to replace the Sender. which sends the contents of a computer’s displays, but typically provides a higher frame rate at the expense of much higher network bandwidth.
Text: Generate attractive text labels and paragraphs with any installed font in any color and with colored or transparent backgrounds. This is great for digital signage or even labeling Sender or Streamer feeds.
Slideshows: Slideshows now have more advanced transitions, so attention-grabbing wipe and fly motions can be used.
There are many other great new features and capabilities, but the ones listed here are the ones I think will have the biggest impact on our already very easy to used display wall software. The Secondary Controller makes content manipulation even easier and more intuitive than before, so customers can take advantage of Hiperwall’s incredible interactivity and flexibility. Share makes sharing content among walls and among sites quick and easy. Even small features, like content previews, make the Hiperwall experience even better than before. Visit Hiperwall.com for more information.
Now that we have released a maintenance update to our third software release and are closing in on our fourth release (likely this Summer), I’ll comment on how our development has changed and how we focus on what to develop and when.
At the start of 2007, the HIPerWall software primarily consisted of two programs: the original TileViewer, which handle big image viewing, and the very interactive NDVIviewer that displayed regular images, movies, video streams and more — I called it MediaViewer (more details on both can be found in this article).
I was lucky to hire Dr. Sung-Jin Kim back to the HIPerWall project as a postdoctoral researcher, and together we set about transforming the software. Note: When I write HIPerWall, it designates the research project, which is distinct from the Hiperwall company.
Sung-Jin developed a new TileViewer that could handle all the MediaViewer features as well as deal with big images much better than the original TileViewer. He added the ability to rotate anything from a playing movie to a billion pixel image in real-time and interactively. This new TileViewer formed the basis of the Hiperwall technology licensed from UCI to the Hiperwall company. Today’s product, however, bears little resemblance to that old code.
Over the years, many of the thousands of visitors we had to HIPerWall expressed their interest in running their software in high resolution on the wall. When told this entailed lots of parallel and distributed computing programming as well as a significant overhaul of their drawing code, people shied away. We decided we needed a way for people to show their applications on the tiled display without having to rewrite their code. We also wanted to provide the ability to use proprietary programs, like PowerPoint, CAD, GIS tools, etc. One way of doing this is to capture the video output of a computer via a capture card, then stream the screen to the wall. We could already stream HD video, so this was certainly a workable solution, but required very expensive (at the time) capture cards that tended to use proprietary codecs. It would also take enormous network bandwidth to stream a high-resolution PC screen. While we have this capability in the Hiperwall software today, we decided it was too brute-force and inelegant (and expensive) for the time.
I decided to use software to capture the screen and send it to the HIPerWall. I developed the ScreenSender (later changed to HiperSender or just Sender) in Java so it can work on Mac, Windows, or Linux, yet have sufficient performance to provide a productive and interactive experience. While the original Sender was fairly primitive and brute-force, today’s Sender software can send faster than many Display Nodes can handle and uses advanced network technology that lets us have tens of Senders displayed simultaneously without seriously taxing the network.
We also started to improve the usability of the software. Initially, the software could be operated by a few key presses, but as we got more content and more capabilities, we knew we had to make a user interface. Sung-Jin and I defined an interface protocol and made a graphical user interface to allow users to choose content to display and to view and changed object properties for displayed objects.
So we had this powerful software that was starting to gain attention. First, the Los Angeles Times published a nice article on the front page of the California section, followed by a radio interview I did for a radio station that broadcasts National Academy of Engineering content, and culminating in a CNN piece that was repeated around the world.
Somewhere around this time, Jeff Greenberg of TechCoastWorks came along to see if he could help us form a company. Because he has been in the computing technology industry for years, he was able to guide our efforts to make the software easy to use for commercial purposes. Around the end of the year, Samsung became interested in licensing our product, so the real software effort began. While it is okay for research software to crash (in fact, if it does, you can claim that you’re pushing the edge), commercial software has to work as expected, and in this case, 24 hours a day, 7 days a week, for months at a time. Therefore, any memory leaks that would have been okay for a short run in the lab were not acceptable, nor were crashes in corner cases. We also had to work hard to improve performance. In the HIPerWall, we used PowerMac G5s with 2 or 4 processors each and advanced graphics cards (for the time). This was a pretty nice environment for our software, but embedded PCs in Samsung’s monitors were not quite as fast and had significantly less graphics horsepower. We used a small 2×2 Samsung wall as a test bench and made the software sufficiently robust that we demonstrated it on a huge 40 panel wall at the Samsung booth at the Infocomm show in Las Vegas in June 2008. We also had to make the software multilingual, which is not as easy as it sounds, even with Java’s support for Unicode characters. The Samsung-licensed version of the software supports 8-10 languages.
Choosing features to develop has changed from making what we think is cool to making things that will help customers and help sales. Our software still handles gigapixel images with aplomb, but for the many control rooms and network operation centers (NOCs) that use Hiperwall, the popular display objects are Senders (for monitoring whatever it is being monitored) and Streamers (to keep an eye on CNN and the weather). For digital signage applications, regular images and movies are popular, along with Streamers and Senders. In order to coordinate these complex display layouts, we provide a way to save the state of the Hiperwall as an Environment, which can be restored easily.
We also added a Slideshow feature that can contain any of our object types with variable timing. It can even have overlays of a company logo, for example. This feature is popular both for digital signage (step through products, etc.) and control rooms where there may be more information than can comfortably fit on the wall at a given time. (Though the right answer is to buy a larger wall! 😎 )
In response to customer requests, we added scheduling capability to show different environments at different times on different days, etc. UCI’s Student Center Hiperwall system makes tremendous use of the scheduler for their very artistic content.
Another example of our responsiveness to customer needs comes from the large Hiperwall-based Samsung UD system installed at the Brussels Airport. They were using 3 infrared cameras to view passengers along the walkways then show the streams on the tiled display along the walkway, as shown below. One camera was on the opposite side, so the video needed to be flipped horizontally. They used another computer to do the flip, which added some delay. Since such a flip is trivial in today’s graphics cards, we added flip options to the Streamer software, thus eliminating the need for extra hardware and delay.
With our next release, we will add many more customer-centric features that will make Hiperwall significantly more powerful, secure, and collaborative, but I will not comment on any here until they are officially announced by the company.
Many people are confused by the spelling of the Hiperwall® name, often misspelling it “Hyperwall” or even “Hyper Wall.”
The name Hiperwall is a registered trademark owned by the University of California (UC Irvine, in particular) and exclusively licensed for commercial use by Hiperwall Inc.
The goal of the research project led by Falko Kuester and myself when we were UCI professors was to develop technology to drive extremely high resolution tiled display walls. Our approach differed from that of other tiled display systems in that we wanted our system to scale easily to huge sizes, so we needed to avoid the centralized rendering system (read potential bottleneck) that most other had. Therefore, we put powerful computers behind the displays. These display nodes perform all the rendering work for their display and had little interaction with other display nodes. We use a central control node that simply commands the display nodes what to display, but doesn’t get in the path of the rendering, thus doesn’t bottleneck the system.
Because of this very distributed and highly parallel computing approach, our system is much more responsive than most other tiled display systems, therefore we called it the Highly Interactive Parallelized display Wall, or HIPerWall for short. The acronym is a little forced, because we had to ignore the word “display,” but the idea is pretty clear. You can see the research project logo on this image of the desktop screen for the HIPerWall Mini system we showed at Apple’s World Wide Developers Conference in 2006. At 72 million pixels screen resolution, the HIPerWall Mini was one of the highest resolution displays in the world at the time.
You’ll note that the “IP” in HIPerWall is highlighted in a different color. This is because we based our technology on the Internet Protocol (IP) rather than proprietary protocols or networks so we could interoperate and use standard, off-the-shelf equipment. This is one of the main reasons Hiperwall systems are so cost-competitive today: we use our advanced software on COTS computers, displays, and networks to create a powerful tiled display system without proprietary servers, amplifiers, and non-scalable bottlenecks.
About the same time we built HIPerWall, NASA Ames built a much smaller tiled display named Hyperwall, which surely led to some name confusion. NASA’s current Hyperwall is even higher resolution than the original 200 MPixel HIPerWall. In the meantime, Apple has made some displays for their stores to show iOS App sales, unfortunately naming them Hyperwall, too.
So to summarize, Hiperwall is the product derived from HIPerWall the research project. NASA and Apple both have Hyperwall systems, which are unrelated to each other and unrelated to Hiperwall.
I will present a talk on “Hiperwall: From Research Project to Product” at the UCI EECS Colloquium at 5PM on Wednesday, Nov. 10, in McDonnell Douglas Engineering Auditorium.
NEC Display Solutions announced today that they are partnering with Hiperwall for our software to power high-resolution display walls (sorry, I can’t stand the more limiting term “video walls”).
The HIPerWall system was a pretty impressive collection of hardware for 2005, with 50 processors (more were added later), 50 GB of RAM, more that 10 TB of storage (we got a gift of 5TB worth of drives for our RAID system from Western Digital), and 50 of the nicest monitors available, but it was the software that really made it special. Remember that HIPerWall is an acronym for Highly Interactive Parallelized Display Wall. We took that interactivity seriously, so we didn’t just want to be able to show a 400 million pixel image of a rat brain, but we want to allow users to pan and zoom the image to visually explore the content. This user interactivity set the HIPerWall software apart from the other tiled display software available at the time and is still a major advantage over competing systems.
The original software was written by Sung-Jin Kim, a doctoral student at the time who was working on distributed rendering of large images. His software, TileViewer, was originally written to use Professor Kane Kim’s TMO distributed real-time middleware, but Sung-Jin ported it to Mac OS X and IP networking so it could work on HIPerWall. TileViewer ran on both the control node and on the display nodes. The control node managed the origin and zoom level of the image, while TileViewer on the display nodes computed exactly where the display was in the overall pixel space, then loaded and rendered the appropriate portion of the image. We preprocessed the images into a hierarchical format so the right level and image tiles (hence the name) could be loaded efficiently. The images were replicated to the display nodes using Apple’s very powerful Remote Desktop software. TileViewer also allowed color manipulation of the image using Cg shaders, so we took advantage of the graphics cards’ power to filter and recolor images. TileViewer didn’t have much of a user interface beyond a few key presses, so Dr. Chris Knox, a postdoctoral scholar at the time, wrote a GTK-based GUI that allowed the user to select an image to explore and then provided zoom and movement buttons that zoomed and panned the image on the HIPerWall. The picture below shows Dr. Chris Knox and Dr. Frank Wessel examining a TileViewer image on HIPerWall. The Macs are visible on the left of the image. The one below that shows Sung-Jin Kim in front of TileViewer on HIPerWall.
TileViewer in use on HIPerWall
Sung-Jin Kim in front of HIPerWall
The HIPerWall was built in the newly built Calit2 building at UCI. We knew HIPerWall was coming, so Professor Falko Kuester, the HIPerWall PI, and I, as Co-PI, worked to get infrastructure in place in the visualization lab. Falko was on the planning committee for the building, so we hoped our needs would be met. The building had good networking in place, though no user-accessible patch panels, but power was “value engineered” out. We quickly determined (blowing a few breakers in the process) that HIPerWall would need a lot more power than was available in the visualization lab at the time. The Calit2/UCI director at the time, Professor Albert Yee, agreed and ordered new power circuits for the lab. Meanwhile, postdocs Kai-Uwe Doerr and Chris Knox were busy assembling the framing and installing monitors into the 11×5 frame designed by Greg Dawe of UCSD. We had a deadline, because the Calit2 Advisory Board was to meet in the new UCI Calit2 building and Director Larry Smarr wanted to show HIPerWall. At somewhere around 3:00 PM on the day before the meeting, the electricians finished installing the power behind the wall. At that point, we moved the racks into place, putting 5 PowerMac G5s on each rack, installing Ethernet cables and plugging in the monitors and Macs to power. Once we booted the system, it turned out that TileViewer just worked. We were done making the system work by 6PM and it was a great surprise for Larry Smarr that HIPerWall was operational for the meeting the next morning.
Larry Smarr at initial HIPerWall demo
Falko Kuester at initial HIPerWall demo
Sung-Jin Kim then turned to distributed visualization of other things, like large datasets and movies, also in a highly interactive manner. The dataset he tackled first was Normalized Difference Vegetation Index data, so the new software was initially named NDVIviewer. This software allowed the import of raw data slabs that could then be color coded and rendered on the HIPerWall. In keeping with the “interactive” theme, each data object could be smoothly moved anywhere on the display wall and zoomed in or out as needed. Once again, the display node software figured out exactly what needed to be rendered where and did so very rapidly. The NDVI data comprised sets of 3D blocks of data that represented vegetation measured over a particular area over time, so each layer was a different timestep. The software allowed the user to navigate forward and backward among these timesteps in order to animate the change in vegetation. The picture below shows NDVIviewer running on HIPerWall showing an NDVI dataset.
NDVI visualization on HIPerWall
NDVIviewer was also able to show an amazing set of functional MRI (fMRI) brain scans. This 800 MB data set held fMRI brain image slices for 5 test subjects who were imaged on 10 different fMRI systems around the country to se whether machines with different calibration or from different manufacturers yield significantly different images (they sure seem to do so), for a total of 50 sets of brain scans. NDVI viewer allowed each scan to be moved anywhere on the HIPerWall, and the used could step through an individual brain by varying the depth or through all simultaneously. In addition, the Cg shader image processing could be used to filter and highlight the images in real-time. Overall, this was an excellent use of the huge visualization space provided by HIPerWall and never failed to impress visitors.
fMRI dataset visualization on HIPerWall
NDVIviewer could do much more than just show data slices. It showed JPEG images with ease, smoothly sliding them anywhere on the wall. It could also show QuickTime movies, using the built-in QuickTime capability of the display node Macs to render the movies, then showing the right portions of the movies in the right place. While this capability had minimal scientific purpose, it was always impressive to visitors, because a playing movie could be resized and moved anywhere on the HIPerWall. The picture below shows a 720p QuickTime movie playing on HIPerWall.
HD movie playing on HIPerWall
Sung-Jin Kim added yet another powerful feature to NDVIviewer that allowed it to show very high-resolution 3D terrain models based on the SOAR engine. SOAR is extremely well suited for tiled display visualization, because it is a “level-of-detail” engine that renders as much as if can of the viewable area based on some desired level of detail (perhaps dependent on frame rate or user preferences). NDVIviewer’s implementation allowed the used to vary the level of detail in real-time, thus smoothing the terrain or rendering sharper detail. The movie below shows SOAR terrain rendering on HIPerWall.
Because of the power and capabilities of NDVIviewer, I started calling it MediaViewer, a name which stuck with almost everyone. An undergraduate student, Duy-Quoc Lai, doing summer research added streaming video capability to MediaViewer, so we could capture Firewire video from our Panasonic HD camera and stream it live to the HIPerWall. Starting with the addition of streaming video in 2006, we started transitioning the software to use the SPDS_Messaging library that I had developed for parallel and distributed processing research in my Scalable Parallel and Distributed Systems laboratory.
In addition to TileViewer and MediaViewer, several other pieces of software were used to drive the HIPerWall. The SAGE engine from the University of Illinois, Chicago’s Electronic Visualization Lab was the tiled display environment for OptIPuter, so we ran it on HIPerWall occasionally. See the movie below for an example of SAGE on HIPerWall.
Dr. Chris Knox wrote a very ambitious viewer for climate data that could access and parse netCDF data for display on the HIPerWall. This allowed us to explore data sets from the UN Intergovernmental Panel on Climate Change (IPCC) on a massive scale. We could see data from many sites at once or many times at once, or both. This outstanding capability was a fine example of what HIPerWall was intended to do. The picture below shows one version of the IPCC viewer running on HIPerWall.
IPCC climate models explored on HIPerWall
Doctoral student Tung-Ju Hsieh also modified the SOAR engine to run on HIPerWall. His software allowed whole-Earth visualization from high-res terrain data sets, as shown in the movie below. This project was built to explore earthquakes by showing hypocenters in 3D space and in relation to each other. As before, each display node only renders the data needed for its displays and only to the level of detail specified to meet the desired performance.
Doctoral student Zhiyu He modified MediaViewer to display genetic data in addition to brain imagery for a project with UCI Drs. Fallon and Potkin to explore genetic bases for Schizophrenia. This research turned out to be very fruitful, as HIPerWall speeded up the discovery process for Drs. Fallon and Potkin. The image below shows Dr. Fallon on the left and Dr. Potkin on the right in front of HIPerWall. Photo taken by Paul Kennedy for UCI.
Drs. Fallon and Potkin in front of HIPerWall
Another software project started on HIPerWall is the Cross-Platform Cluster Graphics Library CGLX. This powerful distributed graphics library makes it possible to port OpenGL applications nearly transparently to tiled displays, thus supporting 3D high-resolution visualization. Professor Falko Kuester and Dr. Kai-Uwe Doerr moved to UCSD at the end of 2006 and continued development of CGLX there. CGLX is now deployed on systems around the world.
In the next article, I will cover new research software from 2007 on when I took over leadership of the project at UCI. This new software forms the basis of the technology licensed to Hiperwall Inc., significantly advanced versions of which are available as part of Samsung UD systems and as products from Hiperwall Inc. In a future post, I will cover the wonderful content we have for HIPerWall (and Hiperwall) and how easy it is to make high-resolution content these days.
Once we won the NSF grant to develop HIPerWall, we had to decide the exact details of the hardware to purchase and nail down the hardware and software architecture. We knew that we wanted high-resolution flat panel monitors driven by powerful computers connected via a Gigabit Ethernet switch. We also knew that we did not want a rendering server (i.e., centralized rendering), but instead wanted the display computers to do all the work. We did want a control node that could coordinate the display computers, but it was only to provide system state to the display nodes and they would independently determine what needed to be rendered on their screen real estate and do so. We were not worried about things like software genlock or extremely tight timing coordination at the time.
We initially planned on using some Viewsonic-rebranded IBM 9 megapixel monitors that were intended for medical applications. These monitors met our “extremely high-res” requirement easily, but had three problems: They took 4 DVI inputs to drive the thing at full resolution, so we needed computers that could handle multiple video cards (not easy back in the AGP days); their refresh rate was something like 43 Hz when driven at full resolution, so movement and videos may not be smooth; and they were being discontinued, so became quite hard to get.
Just as we were getting discouraged, Apple came up with what became our solution: the amazingly beautiful 30″ Cinema Display. This display, which we ultimately chose, is 4 megapixels with reasonable bezel width (for the time), and was nearly as expensive as the computer that drives it. It requires Dual-Link DVI, because at 2560×1600 resolution, it is twice the resolution, hence twice the bandwidth, of a 1920×1080 High-Def TV. At the time, the only commodity machine that could drive the displays was the PowerMac G5. Apple had an agreement with NVIDIA that they were the only company that could sell the GeForce 6800 cards that had Dual-Link DVI for a while, so if we wanted those monitors, we would have to drive them with Macs. Since Frank Wessel and I were Mac users, this was fine with us, because we liked the development environment and Mac OS X. Falko was rightly concerned that Macs had typically lagged Windows in graphics driver support from NVIDIA, which may have meant that we would miss out or be delayed on important performance updates and capabilities. We arranged a trip to Apple HQ in Cupertino (at our own expense, though Apple did give us a nice lunch) to meet with some of Apple’s hardware and software leadership so we could make sure the G5s would work for us. We learned a few interesting things, but one that sticks with me is Apple’s philosophy of hiding hardware details. Both Windows and Linux allow programmers to set CPU affinity so a thread is locked to a CPU in order to prevent cache interference and pollution due to arbitrary scheduling (this was a big problem in operating systems at the time, but has been remedied somewhat since). Apple refused to expose an affinity API, because they figured the OS knew better than the programmers, just as Steve Jobs knows better than everyone else about everything (OK, so that’s a reasonable point). While we could live with that restriction, I was amused at the (possibly correct) assumption that programmers don’t know best.
Once we decided on the Apple 30″ Cinema Display and the PowerMac G5, we carefully worked to devise the right wall configuration to fit within our budget. We ended up deciding on an array of 55 monitors, 5 high and 11 wide. With the help of Greg Dawe from Calit2 at UCSD, we designed and contracted for a frame that would attach to the VESA mounts on the monitors. We ordered 10 PowerMac G5s (2.5 GHz wit 2GB RAM) and 10 monitors, so we could build a small 3×3 configuration and make sure things were working. Because these were dual-core G5s, I took one over to my Scalable Parallel and Distributed Systems (SPDS) Lab so one of my Ph.D. students could experiment to measure the cache-to-cache bandwidth. Unfortunately, someone broke into my lab (and a few others) and stole the G5, as well as a couple Dell machines and my PowerBook G3. Since the university is self-insured and the value of everything was probably less that $5000, we didn’t get any reimbursement. As a side note, I did install a video camera in my lab, which helped capture the guy when he came back for more.
Initial HIPerWall prototype system
The 3×3 wall was a success, but we decided to drive two monitors with each Mac, because the performance was pretty good and we could save some money. Because we built the wall 5 monitors high, we couldn’t easily use vertical pairs per machine, so we decided to skip the 11th column, which is how the HIPerWall ended up with 50 monitors and only 200 megapixels of resolution. Next time, I’ll write about the software.
This is my attempt to relate the history of the Highly Interactive Parallelized display Wall (HIPerWall) research project that led to the development of some of the highest resolution tiled display walls in the world and eventually led to Hiperwall Inc., which commercialized the technology. This is the first part of several that will explore the origins, architecture, and software evolution of the HIPerWall and related projects.
The project was conceived as a result of collaborative brainstorming between myself and my c0lleague Falko Kuester, an expert in computer graphics and visualization. For a few years, we had been exploring project ideas to combine large-scale parallel and distributed computing with visualization to allow scientists to explore enormous data sets. An earlier proposal to build a 100 megapixel cave wasn’t funded, but was well enough received that we were encouraged that we were on the right track.
We saw a Major Research Instrumentation opportunity from the National Science Foundation and decided to propose a flat-panel based high resolution display system. There were other, somewhat similar systems being developed, including one from Jason Leigh at the Electronic Visualization Laboratory at UIC called SAGE. These other systems made architectural choices and control choices that we wanted to try differently. For example, the best SAGE systems at the time consisted of a rendering cluster connected by 10Gbps networks to the machines driving the displays, thus turning all the data to be rendered into network traffic. We wanted to develop an approach that worked very well over 1Gbps networks, which were becoming common and inexpensive at the time. We also intended to make the system highly interactive and flexible enough to show lots of different data types at once.
We wrote an NSF MRI proposal entitled HIPerWall:Development of a High-Performance Visualization System for Collaborative Earth System Sciences asking for $393,533. We got a great deal of help from Dr. Frank Wessel, who led UCI’s Research Computing effort, in developing the project management approach and with reviewing and integration of the proposal. We included several Co-PIs from appropriate application disciplines, including pollution and climate modelling, and hydrology.
The proposal was particularly well-timed because of the pending completion of the California Institute of Telecommunications and Information Technology (Calit2) building at UCI. The HIPerWall would have a prime spot in the visualization lab of the new building, thus would not have to fight for space with existing project. The proposal also explored the connectivity to the OptIPuter, Larry Smarr’s ambitious project to redefine computing infrastructure, and to Charlie Zender’s Earth System Modelling Facility, an IBM supercomputer at UCI.
I got the call from the program manager that we won the proposal and we needed to prepare a revised budget, because as with most NSF proposals, they were cutting the budget somewhat. I called Falko and he quickly called the program manager back. He was sufficiently convincing and enthusiastic, that all the money was restored, as the NSF project page shows.
The next part of this series will cover the hardware and initial software architecture of the HIPerWall.
For those who don’t know, I left my academic position at UCI after the 2009-10 academic year and am now Chief Scientist at Hiperwall Inc. full time.
Hiperwall is keeping me very busy as we are getting ready to release our version 1.2 software. This new software is significantly enhanced from our first release. We added a powerful slideshow creator/editor, made the Sender more capable, added GPU assist and other enhancements to the Streamer, and introduced a scheduling capability to allow the wall to switch environments unattended. We also added a simple web services interface to allow control of the wall via web browsers (including iPad and iPhone) and other networked control devices. Under the hood, we provide a faster and more intuitive content manager.
Once the new version is done, we have lots of ideas for future capabilities, so keep your eyes on this space and hiperwall.com.
Comments are closed 
