We have implemented commands that provide dynamic cluster configuration. With these commands, it is possible to specify a continuum of session rendering configurations, and providing for changes in the number of processors in a cluster and image subdivisions across groups of clusters. These commands affect the rendering efficiency and latency characteristics of the rendering engine and can be used in different ways depending on the particular application. For instance, the configuration to generate overnight animations might be different than the configuration to provide real-time response.
Figure: Default schedule for 4 clusters.
:my_session cluster 8 -group 0 1 2 3.
Figure: :my_session cluster 8
-group 0 0 1 1.
One can issue the following commands to change the way rendering is performed:
pvr> :brain partition 34 (34 = 84+2, each session needs at least 2 service processors)
pvr> :brain cluster 8
pvr> :brain cluster 8 -group 0 0 1 1
The first cluster command specifies that clusters of 8 processors each will be used and that each cluster belongs to a different group (this is the default, see Figure 5). The second cluster command specifies that 4 clusters of 8 processors will be used, but that the first two are in group 0, thus dividing images i mod 2 among them, and the last two are in group 1, dividing images (i+1) mod 2 among them (Figure 6).
The cluster command gives the client complete control to fine tune the rendering process. This command has three parameters:
The client can issue :my_session cluster 8 -image_size 640 480 -group 0 0 1 1 2 2 3 3 4 4, to specify clusters of 8 processors. The numbers actually specify the group of clusters, that is, ``0 0 1 1 2 2 3 3'' means that the first two clusters belong to the same group, which in turn implies they calculate the same image concurrently, each performing half of the work. The same follows for the other clusters.
The system tries to accommodate all choices, but if impossible, it might ease some parameters (e.g., if there is not enough bandwidth to send images to the client, the system might reduce the image size). The command returns the actual allocation for each resource. The default is to spread images across as many clusters as possible, with each cluster in a group by itself. Memory is usually the limiting factor.