Jean-Luc Dery (dery++at++Discreet.COM)
Mon, 23 Mar 1998 16:48:47 -0500
I remember reading a few mails concerning pfTexture memory management in which
there was mention of a problem with freeing/releasing texture memory. But I
don't recall reading any response to those mails. We are currently having the
same problem and would need a fix or work around soon.
I've gone through the archive to retrace those messages and have attached them
here.
Could anyone help "us" on this issue; on are side, it's very important and kind
of urgent. If more details are needed to investigate further, I will be happy
to provide more inputs although I think the previous messages are quite
explicit.
Thanks in advance for your help,
Jean-Luc
-- _____________________________________________________________________________Jean-Luc Dery Discreet Logic System Engineer 10 Duke Street 3-D Graphics Technology Montreal (Quebec), Canada, H3C 2L7 Tel: (514) 954-7239 Email: dery++at++discreet.com Fax: (514) 393-0110 _____________________________________________________________________________
Here is a small fragment of code, including all the nasty debug stuff that I've been using to try to figure what's going on. The routine is called in the PostDraw routine to clean up texture files that are no longer needed. There is a list of textures and a list of codes. At the appropriate times, the app process has found that some textures are no longer needed and sets the code. They are deleted here at the end of the draw process when they are no longer in use. The class TextureFile simply inherits from pfTexture (according the manual on how to subclass). All it does is keep track of the file that the texture belongs to and reads the texture from the file into memory when needed. The TextureFiles are created in shared memory and the, in this case, the program is running as a single process.
Then main problem that I'm having is that the texture is not freed. The statement at line 11 is true, showing that the reference count on the texture is 1, then unrefDelete should delete the texture, but the return value from the call is false, indicating that it did not delete it. The reference count printed in line 14 is still 1.
Under what conditions does unrefDelete not actually delete the memory (besides the obvious when the reference count is greater than 0? The destructor in TextureFile is virtual but it is not being called.
Any help on this would be greatly appreciated.
Thanks, Bill Volz
1 void DataCache1D::cleanUp(void) 2 { 3 int draw_buf = (app_buf + 1) % nbuf; 4 short *code = (short*) code_buf->get(draw_buf); 5 pfList *files = (pfList*) files_buf->get(draw_buf); 6 TextureFile *c; 7 for(int i = 0;i < nx; i++) { 8 if(code[i] <= 1) { 9 c = (TextureFile *) files->get(i); 10 if(c) { 11 if(c->ref() == 1) cerr << "deleting i = " << i << endl; 12 if(c->isLoaded()) c->idle(); 13 if(!c->unrefDelete()) cerr << "did not delete " << i << endl; 14 cerr << "refcount is now " << c->ref() << endl; 15 files->set(i,0); 16 } 17 } 18 } 19 }
======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer++at++sgi.com Admin. requests: info-performer-request++at++sgi.com
Hi !
I have a problem with my texture memory on an Ocatane MXI...
Displaying a simple scene with 5 textures, 2 of these keep bumping each other out of the texture memory. Now I could understand this if they where HUGE textures (don't I have 4 Megs of texture with an MXI ?) but the where puny little 128x128 16 bits images...
I am using the texture->idle() to free-up unused textures and texture->isLoaded() to keep track of who is in memory.
Earlier on in my program, I loaded a few big textures and then, "idled" them when I didn't need them anymore. Indeed "isLoaded" tells me that they are no longer loaded, but just to be sure, I replaced these big textures by smaller one and ... the problem disapered! Now I'm baffled!
How can I get rid of these textures when I don't need them ? (I've put a call-back in the draw process of every node using textures, so I am sure they are not called anymore, and yet they take up space ?)
How is the texture memory managed ? I more or less expected something like normal memory (page aging or something like that...). If this whas the case, even if "idle" didn't work, the small textures should take the place of the old unused ones. An yet, the small textures keep bumping each other out...
_______________________________________________________ Yves Martel Signifi.gVR mailto:Martel++at++signifi.com 417 St-pierre suite 208 Tel: (514) 288-1453 Montreal, QC, CANADA Fax: (514) 288-4112 H2Y 2M4 ======================================================================= 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
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:04 PDT