Re: pfPipeWindow performance effects

New Message Reply Date view Thread view Subject view Author view

Sharon Clay (src++at++rose.asd.sgi.com)
Fri, 16 Aug 1996 17:59:11 -0700


+>---- On Aug 16, 7:32pm, Mark Visconti wrote:
> Subject: pfPipeWindow performance effects
->From guest++at++holodeck.csd.sgi.com Fri Aug 16 16:48:33 1996
->Date: Fri, 16 Aug 1996 19:32:03 -0400 (EDT)
->From: Mark Visconti <visconti++at++acusoft.com>
->To: info-performer++at++sgi.com
->Subject: pfPipeWindow performance effects
->
-> Are there any performance issues when using multiple pfPipeWindows
->on a single pipe ? I realize multiple pfPipes is a "bad thing",
->but have not seen any mention of problems with pfPipeWindows.
->It is significantly faster (High Impact) to run one pfPipeWindow with
->multiple pfChannels than a single pfPipeWindow per pfChannel.

This is because each pfPipeWindow has a separate graphics context so
when you have to change pfPipeWindows, a graphics context switch occurs.
One additional issue is the management of textures and display lists
between graphics contexts. By default separate graphics
contexts do _not_ share textures which means that you might be
running out of texture memory from duplicated textures.
You can verify if this is the case with performer graphics stats - they
will show texture downloads happening.
If this is your trouble, you can attach multiple pfPipeWindows (the
default Performer share mask specifies to share GL objects, PFWIN_SHARE_GL_OBJS).

        pfAttachPWin(pw0, pw1);

The additional performance issues with pfPipes comes from the fact
that each pfPipe gets a separate cull and draw process and you don't
want multiple draw processes thrashing on a single graphics pipe.

->Should each pfChannel under their specific pfPipeWindow share
->PFCHAN_SWAPBUFFERS ?

As it turns out, we currently always swap all pfPipeWindows of a pfPipe at the same
time, as opposed to when each is done drawing.
However, you should go ahead and specify this if it is definitely what
you want in case it is important in the future.

-> Are there other attributes that should be shared to optimize performance?

As above, share GL_OBJS across windows.

->Is there a better way (related to performance) to do
->several pfPipeVideoChannels on the IR than multiple pfPipeWindows ?

A pfPipeWindow can have have multiple pfPipeVideoChannels.
You definitey should not use multiple pfPipeWidnows just for managing
video channels.

src.

-- 
-----{-----{---++at++   -----{----{---++at++   -----{----{---++at++   -----{----{---++at++
Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev.
src++at++sgi.com  (415) 933 - 1002  FAX: (415) 965 - 2658  MS 8U-590
http://www.sgi.com/Technology/Performer/
-----{-----{---++at++   -----{----{---++at++   -----{----{---++at++   -----{----{---++at++

attached mail follows:


Date: Fri, 16 Aug 1996 19:32:03 -0400 (EDT)
From: Mark Visconti
To: info-performer++at++sgi.com
Subject: pfPipeWindow performance effects
Are there any performance issues when using multiple pfPipeWindows on a single pipe ? I realize multiple pfPipes is a "bad thing", but have not seen any mention of problems with pfPipeWindows. It is significantly faster (High Impact) to run one pfPipeWindow with multiple pfChannels than a single pfPipeWindow per pfChannel. Should each pfChannel under their specific pfPipeWindow share PFCHAN_SWAPBUFFERS ? Are there other attributes that should be shared to optimize performance? Is there a better way (related to performance) to do several pfPipeVideoChannels on the IR than multiple pfPipeWindows ?

Thanks, Mark Visconti AcuSoft, Inc. visconti++at++acusoft.com

======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer++at++sgi.com Admin. requests: info-performer-request++at++sgi.com

======================================================================= 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:53:22 PDT

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