Jean-Luc Dery (dery++at++discreet.com)
Fri, 29 May 1998 12:07:09 -0400
I've been trying to figure the Performance problem in the APP process in
Performer 2.2. This mail refers to the one I sent earlier this week. Here's
what I have so far:
1 - I'm pretty sure that the application is sending window size change events
even if the window is not really changing size. And I think that this is
happening within Performer.
2- Indeed, setting the pfPipeWindow PFPWIN_TYPE_NOXEVENTS solves the problem,
but this is not an acceptable solution, well not for us.
3- Perfly is suffering from this disease two (FIIIOUUUU).
Conditions for reproducing the problem:
- ONYX2/4CPU (so that we can lock down processes)
- phase set to PFPHASE_LOCK
- multi processing set to PFMP_APP_CULL_DRAW
- lock all processes on CPU's (just locking the DRAW process does not make the
system behave badly)
- resize the pfPipeWindow
Here's how to see what's going on:
1- Start perfly -> perfly -L -m6 -n4 -W720,486 shinycow.obj (I like that one)
2- Attach "par" command to APP process -> par -s -SS -P<whatever>
3- Or attach "par" command to APP process and use grep to only see X call; it
makes it easier to monitor -> par -s -SS -P<whatever> | grep read
4- Using the mouse, move (not resize) the PF output window. You will see a few
read commands go through in the par session which is perfectly normal, we're
moving the window through the X server. Repeat as many times as you want, its
behaving properly.
5- NOW, using the mouse again, resize the PF output window. You will see read
commands go through in the par session and they never stop. The resize state
procedure becomes sticky and the APP stage is requested to resize the PF window
at every frame.
6- If you want to continue, you can stall the draw process with dbx. You will
then notice that although the APP is waiting, it never receives X resizing
calls. In this last experience, just use par -s -SS -P<whatever>.
Conclusions:
When the APP stage process is locked on a CPU, internal handling of the
pfPipeWindow for managing the window starts behaving badly. The sticky resizing
problem is most certainly something that as to do with the DRAW process.
What I need:
Is there a way, to get rid of this cleanly. We do need to lock down process in
order to manage and balance our system. If this is a problem in Performer 2.2,
could we temporarily hack it until its fixed. Something like accessing specific
memory location through pointers to reset some internal flag ???
We need to upgrade to PF2.2 and would appreciate if this issue could be
resolved soon.
Thanks for your support on this and for any suggestions.
Jean-Luc
-- _____________________________________________________________________________Jean-Luc Dery Discreet Logic Technical Leader 10 Duke Street 3-D Graphics Technology and Montreal (Quebec), Canada, H3C 2L7 Realtime Systems Tel: (514) 954-7239 Email: jean-lucD++at++discreet.com Fax: (514) 393-0110 _____________________________________________________________________________ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer++at++sgi.com Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:27 PDT