Visapult Campaign - Feb 11, 2000

During the transition from IBRAVR to Visapult, we did a preliminary instrumentation of the new source with Netlogger. The results are shown in the image below.

There were three significant design changes between IBRAVR and Visapult. The first is that the viewer and backEnd are now pipelined. That means that while the backEnd is rendering Frame I, the viewer is rendering Frame I-1. Overall, this means that the aggregate throughput will be much greater than the previous design. In the limit, the bottleneck in this diagram is the parallel software rendering engine on the back end.

Second, the communication framework, or protocol, has been streamlined. Previously, there was per-frame communication from the viewer back to the backend. We have moved all session-static parameters to a single communication at the beginning of the application. This was required to implement the pipelined-parallel architecture.

Third, the actual transmission of data from the backend to the viewer was compartmentalized into two stages. A "light payload" stage consists of a single ASCII string containing config parameters that describe what sort of vis data is coming over. Following is a "heavy payload" that contains all the textures, data and geom (if any) associated with the vis for the current frame. Inserted into this layer is a mechanism that does (almost) streaming conversion of IEEE floats, an "endian engine". This addition removes previous restrictions (which we prefer not to list here).

As the above diagram shows, the first two frames in the viewer have very little delay, as the payload from the back end piles up in the communication channel. In subsequent frames, the viewer ends up blocking waiting for rendering to occur. This is good, because we can now concentrate on making the rendering engine faster.