<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
1. One timing had Cull(2.22)+Draw(3.81)+GPU(3.86)=9.89ms @ 59.99Hz 
(good)<br>
<br>
Now all I did was trackball the eyepoint to another location in the
scene, and got:<br>
2. Cull(0.64)+Draw(0.90)+GPU(0.92)=2.46ms @ 46.46Hz frame rate.<br>
<br>
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!<br>
<br>
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.<br>
<br>
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.<br>
<br>
Bob.<br>
<br>
---------------------------------------------------------------------------------------<br>
Robert Osfield wrote:
<blockquote
 cite="mid:7ffb8e9b0807080129j6f06c1b7j116380ebdd6f0b84@mail.gmail.com"
 type="cite">
  <pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a>


  </pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<pre wrap="">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: <a
 class="moz-txt-link-abbreviated" href="mailto:bob@BAL4.com">bob@BAL4.com</a>
<i>"Solutions in four dimensions" with <b>fourDscape</b>®</i>
</pre>
</div>
</body>
</html>