Re: Display List

New Message Reply Date view Thread view Subject view Author view

Rémi Arnaud (remi++at++remi.engr.sgi.com)
Mon, 18 Aug 1997 22:43:08 -0700 (PDT)

TJANDRASA, HADI M. wrote:
>
> Hi Performers,
>
> we are designing an out-the-window (OTW) simulation with a head-up
> display (HUD) overlaying the OTW scene on a multiprocessor
> (APP_CULL_DRAW) mode. So far, It works fine when we use OpenGL
> immediate mode. We want to use an OpenGL display list (non-immediate
> mode) and create a test program, but the HUD is not rendered; however,
> the HUD is rendered when we change to a single processor (APPCULLDRAW)
> mode (or perhaps my OpenGL display list test program is incorrectly
> implemented for multiprocessing mode?).
>
> The reason to use the display list is to shift the processing time from
> the DRAW (immediate) to the APP (display list) process. Note that we
> will eventually use a dynamic display list, traversing the code for
> updating vertices.
>
> On a multiprocessor mode, my questions are:
>
> 1) According to the Peformer Programmer's Guide and 'man' pages,
> Performer's pf display list should be used for multiprocessing. Why
> can't I use the OpenGL display list?
>
> 2) If I use the Performer's pf display list, do I have to create a GSET
> node for the HUD and attached it to the OTW scene graph? I have looked
> at the examples in .../libpr/ directory for the pf display list but
> still have no clues.
>

  OpenGL needs a context to be able to talk to the graphic pipeline (draw
  anything). Having more than one application talking to the graphic
  is not very efficient at it cause OpenGL context switching, that's why
  Performer has a Draw process, that is the only process talking to the
  pipeline at a time. Performer has a Display List that capture all
  performer draw/apply command, so the display list can be executed in
  the Draw process in an efficient way.

  If you want a process to create display list for the Draw Process, this
  process must have a shared space (sproc) and have a context that share
  the texture and display list from the Draw Process (see glXCreateContext()).
  The App process is forked, and does not have a graphic context...
  If you go that way, you will have one more problem that is how to synchronize
  the HUD with the rest of the simulation. If the APP creates a new HUD that
  is going to be displaed immediatly by the DrawProcess, but you are running
  in a CULL/DRAW pipeline model, the HUD will not be in phase with the
  main image, exactly 1 frame too early in that case.

  What you can do, is using the performer GeoSet objects, and the pfCycleBuffer that
  let you change a geoset in the application, and get the right information
  to the draw process. You can also use a Performer display list that you
  will compute in the app, and render in the Draw Process. Even in that case
  you will appreciate the pfCycleBuffer mechanism that will help you to manage
  the memory associated with that.

  Regards

    _ / _ _
|_) _ ._ _ o /\ |_)|\ | /\ | || \
| \(/_| | || /--\| \| \|/--\|_||_/
                                           
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com

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:55:45 PDT

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