On 9/18/06, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
Please refer to this article (a bit old, but has relevant diagrams):
http://donburns.net/OSG/Articles/OSGMP/
This article looks at multi-buffered Multipipe systems and attempts to define an improved simplified approach. In fact, it was the basis for the Producer model.
Note on Figure 3 a multi-buffered MP "traditional" model. As an SGI systems engineer, we loved this diagram because it caused customers to feel the need to buy more CPUs.
Now, for latency. Note that an event occuring during Frame 0, will not affect the visual scene until the third frame later: anywhere from 32 to 48 milliseconds later. Now refer to figure 8. It only displays only one pipe, but it could easily have N pipes running with parallel cul/dispatch pairs and parallel draw.
This approach considers the fact that CPU's and GPU's run in parallel, and uses a phase shifted approach between the frame rate on the CPU and the frame rate on the GPU. Note that DRAW begins drawing the results of an event that occurred during the Update (APP or PreCull, as it is named in the diagram) phase of the current frame. Latency is less than two frames (and more like a frame and a half).
If this were a multibuffered system, we would have to wait until the next frame to synchronize the buffers. At best we could start feeding the pipe sooner by combining cull and dispatch into one thread (as we do in Producer), but latency would be somewhere between two and three frames, even so.
You can't get away from latency, but you can decrease or increase it by your architectural choices.
Hi Don,
A couple of nit-picks...
On Fri, 2006-09-15 at 07:13 -0600, Don Burns wrote:
> OSG uses a read-only protection of data on a single copy of the scene
> graph for each of the downstream phases. The advantages of this
> approach, at least meets the problems of a multi-buffered approach
> mentioned above. The one rule that this imposes, is that you cannot
> modify the scene graph during the cull/draw phase.
I assume these "downstream phases" introduce latency as with any
pipeline configuration? How deep is the OSG pipeline?
Please refer to this article (a bit old, but has relevant diagrams):
http://donburns.net/OSG/Articles/OSGMP/
This article looks at multi-buffered Multipipe systems and attempts to define an improved simplified approach. In fact, it was the basis for the Producer model.
Note on Figure 3 a multi-buffered MP "traditional" model. As an SGI systems engineer, we loved this diagram because it caused customers to feel the need to buy more CPUs.
Now, for latency. Note that an event occuring during Frame 0, will not affect the visual scene until the third frame later: anywhere from 32 to 48 milliseconds later. Now refer to figure 8. It only displays only one pipe, but it could easily have N pipes running with parallel cul/dispatch pairs and parallel draw.
This approach considers the fact that CPU's and GPU's run in parallel, and uses a phase shifted approach between the frame rate on the CPU and the frame rate on the GPU. Note that DRAW begins drawing the results of an event that occurred during the Update (APP or PreCull, as it is named in the diagram) phase of the current frame. Latency is less than two frames (and more like a frame and a half).
If this were a multibuffered system, we would have to wait until the next frame to synchronize the buffers. At best we could start feeding the pipe sooner by combining cull and dispatch into one thread (as we do in Producer), but latency would be somewhere between two and three frames, even so.
Also another concern (as you know :-) of cull/draw modifications is
respecting real-time and time-of-applicability of an input event that is
reflected in the scene. Rendering the scene representing time T should
not be affected by an event at T+1 and directly accessing the cull/draw
stage of a pipeline would do that. A system of timestamps can play
around with dataflow in the simulation to minimize latency but usually
not to push "future events" into the past.
> But this is an easy rule to live with. If one really, really needs to
> modify the scene graph during this time, it is a simple exercise to
> effect double buffering of the scene graph, allowing a separate thread
> to work on the buffer that is not being used by cull/draw pairs.
> Double buffering is a far cry from Multi-buffering and it retains
> nearly the linear scalability of a non-buffered approach.
>
> One other disadvantage of a mult-buffered system is increased latency.
Isn't the presence of a pipeline the reason for the latency?
Multi-buffering is just one way to implement such a pipeline.
You can't get away from latency, but you can decrease or increase it by your architectural choices.
Regards,
Marcus
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
