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

[Curtis L. O. <cu...@fl...>]

Brian R Hill writes:
> 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?

No, we never use ssgLoadXXX functions outside the main render thread.
The reason is that the user could conceivable use any model they
want.  Most likely it would include textures, and thus this would
trigger the execution of opengl commands in the 2nd thread.

If you could guarantee for ever and for always that your models would
never have a texture'd component, then you could probably get away
with using ssgLoadXXX() routines in a 2nd thread.

We get away with paging terrain in a 2nd thread because:

  - we preload all the possible terrain textures

  - we have our own terrain format/loader so we have complete control
    over what the loader does.

  - If we encounter any externally referenced models attached to a
    terrain chunk, we shove those on the end of a queue for the main
    render thread to load.

  - The final scene graph subtree created by the paging thread is
    shoved onto a queue and connected into the main scene graph by the
    main render thread.

> 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)?

You would need to ensure that you are outside of your main render loop
using some sort of locks.  However, in that case, you end up not
gaining much (if anything) with threading vs. doing everything in a
single thread .

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

I guess I don't know enough at this low level to say if this time
slice is usable or not.  Steve or others could probably say something
more informative.  My gut feeling is that on modern hardware, the
graphics card would typically return control back to the app pretty
quickly.

Our motivation for doing threaded tile paging was to minimize pauses
and jitters when a fresh set of tiles needed to be paged in.

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