Gan Wang (gan++at++cavalier.cambridge.com)
Fri, 23 Aug 1996 17:24:18 -0400
That is right.
>It uses a
> time slice approach where the APP is given 4 frames to evaluate the mesh.
The
> CULL just counts frames and toggles the pfSwitch. It waits 5 frames first,
to
> let the APP build the first mesh. This approach does not use
pfCycleBuffer's.
> This was the second algorithm developed and is a bit more scalable but
> introduces more latency.
> ...
> It works because the APP is working on the "tl->active" buffer for 4 frames.
> It only switches it when it's done. The CULL controls the pfSwitch based
upon
> "tl->active" which toggles every 4 frames. So the "double buffer" is toggled
> every four frames as well.
>
I think the number of passes used to evaluate the mesh is irrelevant to the
problem I was talking about. My concern is in the first frame after each time
the pfSwitch is toggled. In this frame time, APP and DRAW would get the same
set of gsets, which APP gets them because they are associated to the pfTerrain
it has newly received due the switch toggle, and DRAW would get at least some
of them which are passed down from CULL that worked on them in the previous
frame (when APP was working on the other set of gsets and the associated
pfTerrain in its last pass). It seems to me that it is the consequence of
"double-buffering pfSwitch" node used in a three stage pipeline. I hope I
described it clearly.
Thanks.
Gan
--Gan Wang
Cambridge Research Associates Office: 703-790-0505 ext.7210 1430 Spring Hill Road, Suite 200 Fax: 703-790-0370 McLean, VA 22102 Internet: gan++at++cambridge.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer++at++sgi.com Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:24 PDT