Re: Performer allocating tex

New Message Reply Date view Thread view Subject view Author view

Marcus (giraffe.asd.sgi.com!sgi.sgi.com!uunet.uu.net!multigen!Marcus)
Wed, 31 May 1995 8:39:26 PST

        Reply to: RE>Performer allocating texture mem
>From: luebke++at++doodad.engr.sgi.com (David Luebke)
>Message-Id: <199505302145.OAA22521++at++doodad.engr.sgi.com>
>Subject: Performer allocating texture mem
>To: info-performer++at++sgihub.corp.sgi.com (Performer-help mailing list)
>Date: Tue, 30 May 1995 14:45:03 -0700 (PDT)
>
>What mechanism does Performer use to allocate texture memory?
>We have RM5s and a flt database with a lot of textures, but after
>loading about 12 megs it freezes up. My theory is that the texture
>memory is getting fragmented (most of our textures are really
>small, 16x16 or smaller) and that the loader is going into a loop
>looking for a large enough chunk of memory to fit that next
>texture. Is this plausible? If so what do I do about it?

The Flight loader(s) rely upon the Performer application to
download texture. They do not download texture directly.
In perfly, for example, a call is made to pfuMakeTexList(3)
after the scenegraph is loaded and then pfuDownloadTexList(3)
is called to load (pfApplyTex(3)) texture memory (if any).
If anything is stalling it's within pfApplyTex I would guess ...

Why do you think that your problem is related to texture downloads?
Can you load the same data base without texture (de-textured)?

>Dave
>--
>David Luebke
>luebke++at++engr.sgi.com

Regards,
Marcus Barnes, Member Technical Staff
MultiGen Inc., 1884 The Alameda, San Jose CA, 95126
PH: 1-408-261-4118 FX: 1-408-247-4329
EMAIL: multigen!marcus++at++uunet.UU.NET

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:51:33 PDT

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