Re: Performance problem: glViewport() called every dra

New Message Reply Date view Thread view Subject view Author view

Jean-Luc Dery (dery++at++discreet.com)
Tue, 6 Oct 1998 09:20:56 -0400

On Oct 6, 11:33am, Moshe Nissim wrote:
> So the question is two-fold
>
> 1. Why is Performer calling glViewport() every pfFrame(), when there was no
real change
> (neither by pfChannel::setViewport of pfChanViewport(), nor window-manager
event
> of window size/position change)
> 2. Why is OpenGL accessing the X-server for every glViewport() call.

I encountered the same problem a while ago. It sounded like this:

->I thus made test comparison between the application versions and have noticed
->bizarre calls that are made in the PF 2.2 version of the software. Complete
->analysis results are available in the attachment. Analysis was made with
->speedshop, par and dbx. It shows that the 2.2 version is updating the
Performer
->output window position through the X server. This is somehow annoying.
->
->The following calls are made in 2.2:
->
->pfPipeWindow::pf_updateWindow
->pfPipeWindow::pf_updateWindowOriginSize <= this is where it gets bizarre
->pfWindow::pr_updateScreenOrigin
->XTranslateCoordinates
->_XReply
-> _XRead
->_X11TransRead
->_X11TransShmBufRead
->_read
->
->The call to pfPipeWindow::pf_updateWindow() is made from pfSync(). In PF 2.1,
->no calls are made to pfWindow::pr_updateScreenOrigin() which happens in PF
2.2.
->Nevertheless, further testing showed that this behavior does not occur on
->ONYX2/2CPU/IR and Octane platforms.

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

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.

The goog thing about this is that the problem is solved in the latest Performer
patch 3229:

  o SCR 611816 - pfPipeWindow resize with forked cull caused slow &
    per-frame X communication

We've upgraded to the patch and it does solve the problem.

I just hope you are experiencing the same problem; else, well, forget this.

Enjoy,

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
_____________________________________________________________________________

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Tue Oct 06 1998 - 06:21:18 PDT

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