MPIRenderModule Deprecation

From ParaQ Wiki
Jump to navigationJump to search

The current (partial) hierarchy of render modules is as follows.

vtkSMLODRenderModuleProxy
|
vtkSMCompositeRenderModuleProxy
| | | |
vtkSMCaveRenderModuleProxy vtkSMIceTDesktopRenderModuleProxy vtkSMMPIRenderModuleProxy vtkSMMultiDisplayRenderModuleProxy
|
vtkSMIceTRenderModuleProxy

The MPIRenderModule proxy is really just what we had before IceTDesktopRenderModule was around. The only real reason it is still around is to support parallel rendering in non-client/server mode. Likewise, MultiDisplayRenderModule is really just the precursor to IcetRenderModule. It is really a hassle to keep these around, and we would really like to get rid of them.

The only sticky point here is that IceT cannot be compiled without MPI. On the off chance that the server was not compiled with MPI, we cannot use IceT. Perhaps the server is a big SMP rendering machine. There is also the even more remote chance the the server was compiled with MPI on but with IceT off. That is very unlikely, and we don't really have to support that well, but we should at least do something better than crashing. We could modify DesktopRenderModule to not use any IceT classes if the server does not support them, but that is a lot of conditionals and some ugly code that is hard to maintain.

To fix the problem, I propose the following change to the hierarchy. Let us add a render module called ClientServerRenderModule that will handle the issues related to rendering in client/server: renderer syncing, image delivery, and data delivery. The new hierarchy will look as follows.

vtkSMLODRenderModuleProxy
|
vtkSMClientServerRenderModuleProxy
|
vtkSMCompositeRenderModuleProxy
| |
vtkSMCaveRenderModuleProxy vtkSMIceTDesktopRenderModuleProxy
|
vtkSMIceTRenderModuleProxy

Note that all of the compositing render modules descend from ClientServerRenderModule. In ParaView 2, this would not make sense since you could do parallel rendering without client/server. With ParaView 3, we have deemed this not possible, so the hierarchy fits.

The new hierarchy solves our problem of what to do if IceT is not available. We simply fall back to ClientServerRenderModule, and do no parallel rendering.