From: Buckley, Bob, CTR (Bob.Buckley-contractor++at++jntf.osd.mil)
Date: 09/30/2003 11:05:00
No amount of code is going to fix your memory swapping problem. Fix that
first before doing anything else.
Also, textures don't get loaded until they are applied in the H/W pipe
(i.e., pfDraw). Since your not calling pfDraw that shouldn't be an issue for
the loading. Non-shared textures for some 10000 objects on something other
than a 320 or 540 (main memory is used for texture memory) will end up
swapping as well. They'll swap anyways given your memory problem.
One other thing comes to mind, are you using these objects between multiple
channels? You need to share attributes between channels. I don't have access
to my workstation right now so I can't tell you the exact calls. (i.e., I
have common textures that get shared, oince they're paged)
There's a routine I use that will page all textures at once. It's a pfu call
and is in Perfly, which you can see when running Performer Town. Load all
your objects then page all texture before starting your sim. Also, flatten
your objects.
Bob Buckley
Raytheon Systems, Inc.
Colorado Springs
-----Original Message-----
From: Christian Stock
To: info-performer++at++sgi.com
Sent: 9/29/03 8:08 PM
Subject: Re: [info-performer] Re: Performer Mailing List Info
Thanks very much for the replies.
No, I'm not loading in between drawFrame, I'm loading everything at
start-up in one go. I can't share any geometry either, and I'm certainly
running out of memory / swap space. I tried converting to pfb files
also,
and while it's maybe a bit faster, it still is much to slow.
>I've seen something similar before.
>
>Performer tries to reuse Performer state (I know for sure from the pfb
>loader); but if there are user data attached to that state (texture,
>material or whatever), it will be seen as a separate object and not
>shared; also the list with all (unique) state objects seen (wich are
>used as potential future candidates for sharing) will grow larger and
>larger which explains the time increase.
I think this is actually exactly what's happening. This explains the
mysteriously high demand of memory and also the decreasing loading
speed.
It even seems as if both the obj and pfb loader at least load the
textures
for every object or file, although the textures should really be shared.
Does performer load textures / materials once per file or for each
object
in every file (ie is the slowdown it file or object dependent)?
Also, is there a known quick fix?
I'll have a look at the performer file loaders myself now, but any help
would be very much appreciated.
Christian
-----------------------------------------------------------------------
List Archives, Info, FAQ: http://www.sgi.com/software/performer/
Open Development Project: http://oss.sgi.com/projects/performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
-----------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Tue Sep 30 2003 - 11:13:29 PDT