On 10/9/06, Jan Ciger <[EMAIL PROTECTED]> wrote:
This is not difficult at all. A generic solution would allow you to allocate a pool of memory which needs to be synchronized at frame time. The implementation for this pool of memory need not be savy of scene graph nodes or any other type of data abstraction. It need only be in a form that the synchronization phase can work with. That is, it can be data delimited by an arbitrary buffer size. Upon updates, buffers are dirtied. At frame time, dirty buffers are broadcast to the network and synchronized by slave nodes.
The luxury we have with many graphics clusters is that we can impose a master/slave architecture, where the slaves are simply readers. Only the master writes to shared buffers, and the slaves simply receive the updates at frame synchronization time.
If we need to have slaves respond by writing to the shared pool, then the issue complicates somewhat, but not so much if we can delimit per/slave boundaries.
If, however, you have more than one slave that can write to a shared buffer, then you must either implement a network mutex, or some other means of cache invalidation to resolve race conditions.
I think what you've described is a simple master-writer/slave-reader architecture.
Consider the fact that we don't actually have to allocate nodes to be shared, only the data that updates them. That data does not actually reside in the scene graph until it is copied there. To make a humvee move, for example, you call
matrixTransform->setMatrix(matrix);
where matrixTransform is the node that moves the vehicle and matrix is where the data containing the vehicle's position and attitude is stored for this frame. In this case, 'matrix' can be allocated in the cluster's shared memory pool (shared between nodes), but matrixTransform does not need to be. Further, a simple update callback on matrixTransform can effect an automatic update of the vehicle's position. You need only , then, synchronize the shared buffers before calling the update traversal.
At the top level of the application then, running on the master, simply updates the position of the vehicles, etc. synchronizes the shared buffers and the positions are updated in graphics about a frame and a half later.
-don
The system should run in a CAVE where the clustering could be required
(could - I am not familiar with their system yet). The problems then
will be how to synchronize the movement of vehicles/insurgents or
projectile trajectories between the machines. This should be possible to
do on the scene graph level, however that takes more than just viewpoint
synchronization. We could probably do an ad-hoc solution synchronizing
only the relevant nodes in the scene graph, but I would prefer a more
generic solution if there is one.
This is not difficult at all. A generic solution would allow you to allocate a pool of memory which needs to be synchronized at frame time. The implementation for this pool of memory need not be savy of scene graph nodes or any other type of data abstraction. It need only be in a form that the synchronization phase can work with. That is, it can be data delimited by an arbitrary buffer size. Upon updates, buffers are dirtied. At frame time, dirty buffers are broadcast to the network and synchronized by slave nodes.
The luxury we have with many graphics clusters is that we can impose a master/slave architecture, where the slaves are simply readers. Only the master writes to shared buffers, and the slaves simply receive the updates at frame synchronization time.
If we need to have slaves respond by writing to the shared pool, then the issue complicates somewhat, but not so much if we can delimit per/slave boundaries.
If, however, you have more than one slave that can write to a shared buffer, then you must either implement a network mutex, or some other means of cache invalidation to resolve race conditions.
I think what you've described is a simple master-writer/slave-reader architecture.
Consider the fact that we don't actually have to allocate nodes to be shared, only the data that updates them. That data does not actually reside in the scene graph until it is copied there. To make a humvee move, for example, you call
matrixTransform->setMatrix(matrix);
where matrixTransform is the node that moves the vehicle and matrix is where the data containing the vehicle's position and attitude is stored for this frame. In this case, 'matrix' can be allocated in the cluster's shared memory pool (shared between nodes), but matrixTransform does not need to be. Further, a simple update callback on matrixTransform can effect an automatic update of the vehicle's position. You need only , then, synchronize the shared buffers before calling the update traversal.
At the top level of the application then, running on the master, simply updates the position of the vehicles, etc. synchronizes the shared buffers and the positions are updated in graphics about a frame and a half later.
-don
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
