Re: multipipe problems, Need help, VLIB, MP, Boom, Fakespace

New Message Reply Date view Thread view Subject view Author view

Ralph Seguin (seguin++at++vr1.engin.umich.edu)
Tue, 22 Nov 1994 13:49:31 -0500


> If you have two sproc threads rendering, you must synchronize them so
> that only one at a time calls GL, which defeats the purpose of having
> a second process for the second pipe. So, you need to fork and set up
> explicit shared memory like Performer does.

Right. So, I do have to do a real fork() (ie, second proc gets a whole
new address space, and whole new copy of GL lib).
I'm going to have to play around with setting up a shared memory arena
and stuffing the geometry data in it. Unfortunately, we do not
have enough time to spend in rewriting the code for Performer
(as much as I'd like to).

I still think it would be real nice if the GL functions took the
window ID for rendering as a parameter. Looks as though that would
have solved a lot of these problems.

> If you want the app to run well on a single pipe, MCO machine, as
> well, you need a mode where it will run with a single rendering
> process driving multiple viewports in a single GL window. Otherwise,
> with multiple windows on the same pipe you'd be context switching
> between them at least once a frame and be unable to share textures.
> With multiple processes rendering simultaneously to the same pipe,
> you'd see even more gfx context switching and performance death.
> In Performer-speak, you always need two pfChannels, but for MCO,
> they are both on the same pfPipe.

Our main concern is better performance on a dual-pipe machine.
Right now with a single process, we are theoretically, only half speed
or less of what we could be.

> It sounds like you need some Performer-based BOOM code. You might be
> able to move your code over by using Performer's multiprocessing and
> channel framework without a scene graph and doing all your own GL
> rendering in callbacks.

Yep. It is our intention to scrap all of the old stuff as soon as we get
the chance to start our next development cycle.

Ideally, we would like to use Inventor and Performer together (Informer?? ;).
Get the nice user interface stuff that Inventor provides combined with the
performance features of Performer. When we do end up doing this, we will
need to be able to totally disable any parentage surrounding the GLX widgets.
Ie, when driving the boom, you should have a full screen GL window.

                        Thanks, Ralph


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:50:41 PDT

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