Re: Double buffers used in ASD sample

New Message	Reply	Date view	Thread view	Subject view	Author view

Marcus Barnes (marcus++at++multigen.com)
Fri, 23 Aug 1996 17:23:26 -0700

Next message: David Chan: "How to load multiple .iv file in a specified position ?"
Previous message: Mark G. Yarbrough: "Re: Texture Memory Resources"
In reply to: Mark G. Yarbrough: "Texture Memory Resources"

On Aug 23, 5:24pm, Gan Wang wrote:
> Subject: Re: Double buffers used in ASD sample
> On Aug 23, 12:11pm, Marcus Barnes wrote:
> > Subject: Re: Double buffers used in ASD sample
> >
> > 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.

No its not ... because of the work done in each time slice by the algorithm.

> 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.

I see what you mean. The APP doesn't know about the pfSwitch setting so it
could potentially conflict with the DRAW. The way it's is setup in the demo,
starting from frame 0, the conflict would happen in frames 8 and 9.

But! the evaluation actually has two sub tasks: evaluating the potential
triangles and "weaving" the final mesh. The weave task actually populates the
geosets and it runs to completion in a single frame. There is no incremental
conflicts. Note that this is an evaluation bottle neck and limits scalability.
Still this demo has handled much of northern california (from 100m dted) with
clipmapping (30 meter texels as I recall) at 60Hz on a properly configured iR.

PS: Improved mechanisms and algorithms are being developed, rest assured.

Regards.

--
   ____ ___  ____  _    Marcus Barnes, Member Technical Staff
  / __ `__ \/ __ `( )   MultiGen Inc. 550 S. Winchester Blvd. STE 500
 / / / / / / /_/ / /    San Jose CA 95128 WEB: http://www.multigen.com
/_/ /_/ /_/\__, /_/     PH:1-408-556-2654 FX:1-408-261-4102
          /____/        EMAIL: marcus++at++multigen.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

Next message: David Chan: "How to load multiple .iv file in a specified position ?"
Previous message: Mark G. Yarbrough: "Re: Texture Memory Resources"
In reply to: Mark G. Yarbrough: "Texture Memory Resources"

New Message	Reply	Date view	Thread view	Subject view	Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:24 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.