Re: Preloading of textures

New Message Reply Date view Thread view Subject view Author view

Stephen Maher (maher++at++holodeck.gsfc.nasa.gov)
Thu, 16 May 1996 12:39:43 -0400 (EDT)


> Hi,
> I'm running on an Onyx RE/2 (5.3) with 2 RM5s. I've experienced problems
> with preloading textures (in GL). I understand that an RM4 has 4 Meg of

I recently observed the same thing and was about to ask the Net!

We have an Onyx RE2 (5.3) with 2 RM4s. Instead of calling
istexloaded(), I simply timed (gettimeofday) how long each
successive texdef/texbind took. (I also actually drew
the texture to prove to me it was there :) I did NOT use
TX_FASTDEFINE.

As soon as I hit 4MB of textures - whammo! - about an order of
magnitude slower - telling me paging had kicked in. (2 RM4's is
8MB of textures, supposedly ;).

The kicker was when I tried it on an Onyx RE2 with *1* RM4 (4 MB);
I got the same results!

What gives?

Steve

--
Stephen.Maher++at++gsfc.nasa.gov                     (301) 286-3368
Scientfic Visualization Studio              (f) (301) 286-1634
Code 932 NASA Goddard Space Flight Center

> > > Hi, > I'm running on an Onyx RE/2 (5.3) with 2 RM5s. I've experienced problems > with preloading textures (in GL). I understand that an RM4 has 4 Meg of > texture memory and an RM5 has 16 Meg of texture memory and that added > RM boards increase your fill rate. However, when I try to preload textures > I can only preload 4 Meg until internal texture management paging takes over > and starts removing early textures. I am using TX_FASTDEFINE when defining > the textures and am "prebinding" to avoid start up delays/ pay attention to > texture bank ordering / etc. I have reduced the problem to this: > I define then pre-bind the textures one after another (all same size 64x64 > shorts). After each def/bind I check to see if the first one is still loaded > (it is the "oldest" one so it seems it would be "paged" out first) with > "istexloaded" (for debug). After I reach the 4 Meg boundary, the first > one returns that it is not loaded. There are no other textures loaded, > there is no mip-mapping, etc. I have tried this on two identical machines > and have gotten the same results. I only thought something was wrong > because the program would "hang" while it shuffled the texture memory. > It seems that 16 Meg of texture memory could handle this ( only need about > 8 Meg for the application). Since it uses a TX_FASTDEFINE token I have > tried binding both a NULL texture and a real texture. I don't even > get to the subtexload at all before the RMs start swapping out texture > space. > > I can send example code if this isn't just an oversight on my part. > > Thanks, > > Neil >


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:52:53 PDT

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