[osg-users] Rendering performance issues

[Bob Balfour]

My main frustration is demonstrated by the second and third timing 
images I had posted, both with VSync on (so 60Hz max frame rate), with a 
single GPU.  Both Event/Update timings are trivial.

1. One timing had Cull(2.22)+Draw(3.81)+GPU(3.86)=9.89ms @ 59.99Hz  (good)

Now all I did was trackball the eyepoint to another location in the 
scene, and got:
2. Cull(0.64)+Draw(0.90)+GPU(0.92)=2.46ms @ 46.46Hz frame rate.

This makes no sense to me.  With 4 times more rendering time(#1) we can 
achieve max frame rate, but with a very light rendering load(#2), our 
frame rate is substantially degraded?  How frustrating is that!

w.r.t. Paul's suggestion about buffer swaps being queued being the cause 
of the Draw/GPU gap, I'm not sure I quite understand how/why that would 
happen, plus if that's a potential cause why moving the eyepoint in my 
example above to a less rendering load would cause it to happen.

Clearly something is causing a large delay, but I'm still quite confused 
as to what it might be, how to track it down, and how to eliminate/avoid it.

Bob.

---------------------------------------------------------------------------------------
Robert Osfield wrote:
> Hi Guys,
>
> The gap between draw dispatch (the yellow bar) and draw GPU (the
> orange bar) is by its nature variable.  The reason is it so variable
> is that I have to estimate the begining of the draw GPU as the OpenGL
> GPU stats extension only provide elapsed time, they don't provide any
> details on absolutely time, while the CPU code is all in absolute
> timings.   As GPU stats are really useful the best I could do is take
> the time that the GPU stats were collected (on the next frame),  which
> gives us a time that we know it was complete by, then estimate that
> GPU work was, I can't recall the exact maths off hand.  The bottom
> line is that it's position is an estimate, but it's length is measure.
>
> As for the frame rate being awful when running with two GPU, this is
> likely to be a driver/OS issue.
>
> W.r.t whether you should use vsynv when you are using
> projectors/LCD's, yes vysn is still required, they still read their
> data via a scan line, so if swap buffer happens during the scan then
> some of the screen will be from the previous frame, and some from the
> next, or it can even be several frames worth on a single frame if your
> frame rate is high.  What you'll see if a tearing across the screen,
> especially visible when you are turning the eye point quickly.
>
> Robert.
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>   

-- 

Robert E. Balfour, Ph.D.
Exec. V.P. & CTO,  BALFOUR Technologies LLC
960 So. Broadway, Suite 108, Hicksville NY 11801
Phone: (516)513-0030  Fax: (516)513-0027  email: bob at BAL4.com
/"Solutions in four dimensions" with *fourDscape*®/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080708/a12a47df/attachment.htm>