Re: [Plib-users] How to run loader and render in separate threads?

[Brian R H. <bh...@cs...>]

Curt,

Thanks for the info. I'm going to browse through the flight gear code to
get a better idea about what I'm up against.

A quick (maybe) question about building sub trees in a separate thread. Do
you use the ssgLoadXXX functions?
My review of the loader code indicated it issues OpenGL commands which
should be either a no-no or do I just have
make sure the rendering thread isn't active at the time (in ssgCullAndDraw
or drawing overlays or glutSwapBuffers)?

My fundamental objective is to be able to use the time waiting for the
glutSwapBuffers command to return.
I can limit the use of this time to non-OpenGL and non-scene graph
processing.

Brian



                                                                                                                                  
                      "Curtis L.                                                                                                  
                      Olson" <curt             To:      pli...@li...                                          
                      @flightgear.org>         cc:                                                                                
                      Sent by:                 Subject: Re: [Plib-users] How to run loader and render in separate threads?        
                      plib-users-admin                                                                                            
                                                                                                                                  
                                                                                                                                  
                      02/20/2003 02:01                                                                                            
                      PM                                                                                                          
                      Please respond                                                                                              
                      to plib-users                                                                                               
                                                                                                                                  
                                                                                                                                  




Brian R Hill writes:
> Does anyone have an example of how to run a loader process (read files,
> create ssg objects, merge into scene graph) and rendering process (glut
and
> ssgcullandraw) in separate threads?

FlightGear does this, but I wouldn't call the code straight forward.
There are a couple things you need to watch out for.

You mustn't *ever* interleave opengl commands between two threads.
This is a recipe for disaster.  OpenGL is not thread safe, you can
think of it as a single resource.  Even worse, it's a state machine so
the order of opengl calls is very important.

Imagine if you are rendering in one thread, and loading a model (and
therefore probably textures) in another; and the opengl commands from
those two threads get interleaved.  Most likely you'll just get a
crash, but if your code somehow survived, you'd still likely get some
bizarre rendering effects.

FlightGear goes to great lengths (and thus complexity) to avoid doing
any opengl commands outside of the main render loop.

We also are careful not to alter the main scene graph while it is
being rendered.

So, we:

  - load all self contained models from the main render loop.
    (Terrain is a specialized case that we have complete control over
    so we can load that in the thread.)

  - In the second thread we don't actually modify the main scene
    graph.  Instead we build up sub trees, push those onto a queue,
    and then have the main thread connect this tree into the main
    scene graph.

  - Likewise, we can lop off a sub tree we want to delete in the main
    thread, and then work on deleting it in a 2nd thread ... however
    if you have multiple instances of objects in your graph you need
    to be really careful.  We ended up not doing this in our 2nd
    thread.  Instead we wrote a routine that deletes "n" elements of a
    subtree and then bails out.  This way we can spread the work of
    deleting a sub tree over several frames, call the routine from the
    main render thread, and not worry about scene graph consistency
    issues.

As you can imagine this all adds a big measure of complexity.  We have
load queues, model load queues, attache queues, free queues, etc.  We
have also found that introducing threading is a great way to add
really subtle and very hard to find bugs to your program.

My advice is to only do threading as a last resort.  It's one thing to
code a simple producer / consumer example for a class, it can be an
entirely different thing to add threading to a large, complex, real
world app.  Beware! :-)

Regards,

Curt.
--
Curtis Olson   IVLab / HumanFIRST Program       FlightGear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
plib-users mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-users