PVR consists of rendering and control components. It augments the Tcl/Tk functionality with a few abstractions to provide transparent control over the parallel machine and easier methods to manipulate rendering. As PVR uses Tcl/Tk, it can be used easily to build larger blocks that can provide more complex interaction between the user and the parallel machines. PVR attempts to provide just enough functionality in the basic system to allow for future development of larger and more complicated applications. It is based on a client/server architecture, where the parallel machines are the servers and the user on the workstation operates a client application. In order for the client to start communication with a server, a session has to be open. Sessions emulate the functionality of a sequential renderer and each session is able to render one data set.
In order to support performance fine tuning, the client has mechanisms to extract detailed configuration and performance information from the sessions. Normally, the calculated defaults should be enough for reasonable speeds, but almost every parameter can be overwritten by the client. One client can have more than one session (see Figure 2), in a single or more machines.
Figure 2: A client application on the workstation has
two sessions in the parallel machine. Each session appears to be a
virtual rendering machine to the client. The user has opened
three sessions, but only two of them have parallel machines
associations.
The use of independent, controllable sessions as the basic unit of computational power gives the client application transparent control of all the parallel machines accessible, without any particular knowledge about their operation or exact performance figures. This method is also very reliable, as it encapsulates all the communication code within a well-defined framework. In order to prevent the user from wasting resources, the system performs simple bookkeeping of resources and a primitive form of admission control. For instance, currently the system tries to estimate the rendering time of every frame, and if the combined bandwidth of the links between the sessions and the client is not enough to support the video stream, it alerts the user. Each session can have its own image resolution, decoupled from the image resolution the client receives. Upon receiving the image the client interpolates it to the desired resolution.
Processors are allocated to a session, which in turn divides them into clusters. Every cluster gets its own copy of the data set (i.e., each cluster can independently render a complete image [MPS92]). The allocation of the processor memory inside each cluster is specific to the rendering algorithm being used on the cluster. Preferably, each processor inside a cluster gets only a small fraction of the complete data set. In order to provide full flexibility during rendering, sessions also create the group of clusters abstraction, where one can specify that clusters be grouped in order to calculate a single image concurrently. With the cluster and group of cluster abstractions, sessions export a portable way to achieve both image- and object-based load balancing, providing for a whole range of tradeoffs between image generation efficiency and latency.
The advantages of clustering processors is very intuitive: the less global communication (even non-existent when each processor is a cluster on its own) the more efficient the image generation is, even though when one image is allocated to one processor the image generation latency would go up. When group of clusters are used, we are trading memory for latency. The characteristics of the particular rendering algorithm, machine limitations and even data set sizes most likely change the tradeoffs. PVR abstractions allow for flexible configurations independent of the exact algorithm details.