Re: Performer Woes

New Message Reply Date view Thread view Subject view Author view

Jan Barglowski (jan++at++archimedes.vislab.navy.mil)
Wed, 22 Oct 1997 11:27:56 -0700 (PDT)

John Auborn wrote:
>
>
> Jan,
>
> I have isolated the locking up of the draw process as the culprit in
> both our otw program and in perfly. Perfly has a -D option to lock the draw
> process down on it's processor (it locks up the whole machine even when you
> are not root!!). Commenting out the corresponding lines in your code makes
> root able to run otw successfully too. It is pitifully slow, but it does run.
>
> I'll look into some more later. I thought you might want to ask you performer mailing list why the -D option on perfly locks up the machine.
>
> John
>
> John Auborn Code 471130D Naval Air Warfare Center Weapons Division
> Chinalake, CA 93555-6100
> (760) 939-2274 (office) (760) 939-0547 (lab)
> (760) 939-6893 (fax)
> auborn++at++chinalake.navy.mil
> http://circe.chinalake.navy.mil (work)
> http://www1.ridgecrest.ca.us/~auborn (home)

Background:
  We upgraded from 1 to 3 Pipes on our iR. 2Gb RAM, Iris 6.2, and
Performer 2.1. Processor locking and non-degrading priorities via
the pfu calls worked well under 1 pipe, but now we cannot lock down
the draw process without locking up (hard) the entire machine!

We are using the same calls as perfly for locking and non-degrading,
and am calling them in the same "places" (initialization-wise), too.

Any suggestions, or is our hardware hosed? ;-)

I can furnish some code fragments, if necessary. I'm at class this
week, so it may be a little slow communicating...

jan

-- 
Jan Anthony Barglowski	              jan++at++chinalake.navy.mil
Real-time Computer Graphics           http://www1.ridgecrest.ca.us/~jan
Naval Air Warfare Center, China Lake  (619) 927-1057


=======================================================================
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:56:08 PDT

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