Re: pfDispList and parallel drawing (bug?)

New Message Reply Date view Thread view Subject view Author view

Andreas Loesch (loesch++at++lola.gsf.de)
Mon, 17 Mar 1997 10:09:17 +0100


On Mar 15, 9:16pm, Rémi Arnaud wrote:
> Subject: Re: pfDispList and parallel drawing (bug?)
> Andreas Loesch wrote:
> >
> > Hi Performers,
> >
> > we are in a situation where we want to get two pfDispList with identical
> > contents drawn by two parallel processes (multipipe configuration). We
ar=
> > e
> > sure that we get everything we need packed in our pfDispLists, but when
w=
> > e
> > try to pfDispList::draw() them in parallel we get awful flickering,
wrong=
> >
> > colors, positions ...
... (snip) ...
>
> That's interesting. In libpf each pfChannel produce each own
> pfDispList, so it is not designed to be used by two draw process
> at the same time.
>
> Before going in further investigations, the 2 process that draw
> the displist are forked, right ? (not sproced)

Actually we tried to use as much of the Performer architecture as possible.
Our two main goals were:
1. provide more than one culling process per channel (our scene graph can
   produce culling times longer than the drawing time)
2. Omit culling almost identical viewing frustums in the stereo viewing case.
   We prefer to cull against a slightly larger frustum and use the result for
   both (left and right eye) channels.

Here is our setup:

cullChannel0 -----> pfPipeWindow0 -> Pipe0
cullChannel1 ---|
| ---|
cullChannelN ---|
drawChannel0 ---|

drawChannel1 -----> pfPipeWindow1 -> Pipe1

The traversalmasks are set up in way that makes the cullChannels divide the
scene into N parts and cull these parts. The drawChannels have a zero mask.

In the (common) drawfunction we us two pfDispList (one for each channel) and
do the following:

if (chan == cullChannelX)
{
        pfDispList0->open();
        chan->draw();
        pfDispList0->close();
        pfDispList1->open();
        chan->draw();
        pfDispList1->close();
}
else // channel is drawChannel
{
        pfDispListY->draw();
}

We assure that drawing of Pipe1 does not start before the "drawing" (i.e. the
setup of the pfDispLists) of the cullChannels has finished. We also take care
that they do not get out of phase.

The multiprocessing scheme of Performer remains intact. We have one
draw-process for each pipe. The cullChannels are assigned to the the
pfPipeWindow to give the desired drawing order.

As you can see, the two pfDispList have the same contents. They give a
perfect result if they are drawn separately, hence the "cull data transfer"
from the cullChannels should work. We tried both, forbidding the
pfDispList->draw() call for one of the drawChannels (no matter which one) or
forcing them to be drawn sequentially. The latter of course doubles the
drawing time =:(((((.

Any ideas? Is there perhaps a non-documented initialization we should do in
order to make the pfDispLists work? Can we access the original
pfChannel.pfDispLists ?

Thanks for your help!

Andi

-- 
Andreas Lösch		GSF - Forschungszentrum für Umwelt und Gesundheit
MEDIS/M3				Phone   : (+49 89) 3187 4458
Ingolstädter Landstr. 1			FAX     : (+49 89) 3187 4243 o. 3326
85764 Neuherberg / GERMANY		E-mail  : loesch++at++gsf.de

===================================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:54:54 PDT

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