Re: [info-performer] Onyx4, multiple compositors.

Date view Thread view Subject view Author view

From: Bernie Kirby (bernie++at++ecr.mu.oz.au)
Date: 07/22/2004 17:43:27


G'day,
Thanks for your response.

> Unfortunately, I'm sitting in front of a Windows machine and the pf3.1
> i have installed on it doesn't have the compositor.C sample or
> pfCompositor man page or any perfly code that contains references to
> the compositor stuff, or even the pfCompositor man page. This stuff
> is probably only shipped on the IRIX version of performer. I also

        Yep, Onyx4, so IRIX it is.

> haven't looked at this kind of thing in a while, so I'll be basing
> this post on some fuzzy memory recollection....
>
> First of all, I think you need to setup a hyperpipe for each
> compositor you're going to use. For example, if you wish to use 6
> pipes, with 2 pipes per compositor, you need to setup 3 hyperpipes
> with two pipes each.
>
        There appears to be a default hyperpipe set up, hyperpipeinfo
returns this (currently):
pipe :0.0 network id 0
pipe :0.1 network id 0
pipe SG-2 network id 0
pipe SG-3 network id 0
pipe :0.4 network id 1
pipe :0.5 network id 1
pipe SG-10 network id 1
pipe SG-11 network id 1
pipe :0.2 network id 2
pipe :0.3 network id 2
pipe SG-6 network id 2
pipe SG-7 network id 2

Which actually raises another problem, when enumerating the names in
the hyperpipes, you get an invalid display name of SG-2 etc...
In my opinion, it shouldn't be listed. ... but that's another matter.
(see glXQueryHyperpipeNetworkSGIX for example).

> i think for each hyperpipe, you'll need a new pfCompositor (i think).
> for each pipe in a hyperpipe, you add that pipe to the corresponding
> pfCompositor.
>
        Did exactly, that, but manually (ie hard coded) the
pipes and display names/screens.

    for (i = 0; i < NumComp; i++) {
            comp[i] = new pfCompositor();

            // Add all relevant pipes to the compositor using their pipe-number.
            // "pipes" contains the info gleened from the hyperpipeinfo program.
            // ie pipes[k}.n is the pipe number
            k = 0;
            for (j = 0 ; j < NumPipesPerComp ; j ++)
                comp[i] -> addChild(pipes[k++].n);

            // Set load-balancing filter coefficient. Valid numbers are in (0..1].
            // The smaller the number, the slower load balancing follows pipe load, and
            // the less noise sensitive it is.
         
            comp[i] -> setVal (PFLOAD_COEFF, 0.1);
            comp[i] -> setMode (PFCOMP_TYPE, PFCOMP_2x1VERT);

            // Add a compositor
            pfHyperpipe2D(comp[i]);
     }

> i think the answer to the COMP_SOFTWARE question is that it was there
> for a feature of the compositors that never came into fruition.
>
        OK, I was just interested.
        
> You shouldn't be seeing a crash when enabling or disabling load
> balancing. i recommend you create a small sample that recreates the
> problem so the pf team and quickly debug and fix the problem for their
> next release.
>
        Trivial to reproduce, just add the call to one of the
compositor.C or compositor2.C examples.
        Another issue is that it appears to print out debug statements such as
Stress[1] = 0.7834
        even with PFNFYLEVEL 1

Also, even with an unmodified example, with 1 compositor and 4 cards/pipes
we get this message:

Also, we get this warning:
PF Warning: glXBindHyperpipeSGIX failed: 5 (GLX_BAD_CONTEXT)

Although it does work ok.

> the other questions you have i cannot immediately answer due to lack
> of man page or source code that you're referencing.
>
> hope this provides some help,

        Yes, it does, I'll look at some other things.

--
Two wrongs don't make a right ... but two wrights make an aeroplane.


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Jul 22 2004 - 17:45:07 PDT