Killing reference counted objects

[TCM]

Thank you very much.

Now another question. Why the reference counter starts with 1 when an object is not used, and goes to 2 when used? The code looks like this:

Code: Select all

--ReferenceCounter;
if (!ReferenceCounter)
{
    delete this;
    return true;
}

But isn't more robust to delete when the reference counter is zero? Like this:

Code: Select all

if (ReferenceCounter)
{
    --ReferenceCounter;
}
else
{
    delete this;
    return true;
}

Just asking... i might be a good reason for the counter to start at 1 when not used.


Later edit : this would mean that when an node using a mesh is removed, the mesh will be also removed (if the counter was starting at 0). Right ?

[CuteAlien]

Don't know why it was implemented as it is - I guess both is possible (I think some other IUnknown interfaces request an extra addRef to get the reference counter up to 1). Don't know if there are any real advantages/disadvantages of doing it either way.

[TCM]

And getting back... It seems that textures are not reference counted.

[slavik262]

The reference counter starts at 1 because conceptually, allocating an object gives you one reference to the object. When you create a custom scene node using new, you have a reference to the object. When you attach it to the scene manager, it grabs it, and then you drop it. The reference count is now 1 again

I don't think it really matters which way you do it; it's more of a preference.

[CuteAlien]

Textures are reference counted, but I think materials do not grab them. So they are indeed only grabbed by the texture-cache.

[TCM]

Textures are reference counted, but I think materials do not grab them. So they are indeed only grabbed by the texture-cache.

Yes, that's what i saw. The reference counter might be useful in a dynamic environment. Say a game that adds and removes meshes and textures. When a reference counter gets to zero (or 1, whichever start value is used) then a memory manager knows it's not used any more by any object, so it is deleted. Given that a texture will be used by more than one material, and a mesh will be used by more than one scene node.

So i think textures should also be grabbed.

[slavik262]

The texture cache automatically holds on to all loaded textures until you manually remove them or until the driver is reset. This is done for the exact reason you mentioned: multiple materials and meshes may use the same texture. By holding onto them, time is saved since the GPU never has to reload the textures.

[CuteAlien]

Yeah, although to be true - it makes it hard getting rid of textures when for example removing a loaded level. The way I do that is either ignoring it (which works if you don't have too many textures) or having my own texture-management for scenes (using xml's which contain all texture-names used in a scene).

[TCM]

having my own texture-management for scenes.

Yes, i am also using something similar. But then there is another problem. A referenced object can be deleted by the object using it. So if you drop it more times then grabbing it, then you will get a big error. But there is no way to tell if that object is still valid, or somehow it got deleted by another object.

Reference counting is good. But i think dropping the object should be done by the user. It's ok if the ref counter goes down to 1. But if it gets deleted automatically (as the above code clearly shows) then you do not have control over the object, and you can easy end up in accessing an invalid pointer (which will not go to zero by itself, so no way to test).

[TCM]

Also, a little bit off-topic, but related. Is there ANY way to get the amount of physical memory used by textures or meshes (or so on...) ?

It would be nice if you could also check the total memory used along with adding and removing.

[CuteAlien]

My way of checking memory is using the taskmanager (or htop and valgrind on Linux).

[hybrid]

Unfortunately, there's no cross-platform way to get the texture memory usage. I've added a debug output some weeks ago, which prints the memory information on some NVidia and ATI cards. But it's hard to do this for all cards and systems. And do you need CPU or GPU memory?

[TCM]

And do you need CPU or GPU memory?

Good question....

But i guess, it all comes to both. The textures are stored in GPU memory, i am not very sure where the models are stored.

My main concern is adding and removing objects dynamically (during the game). Not just adding and removing them, but doing this as clean as possible.

[Qps]

Hi,

I created a scenenode which dynamically loads/drops some meshbuffers, however im having some trouble with dropping the meshes.

Now i noticed that my application has a memory leak, I use the following code to drop the mesh:

Code: Select all

 
if(!m_pMeshBuffer->drop()
{       
  CString sMsg;
  sMsg.Format("%s: Mesh was not dropped MBrefCount:%d \n", __FUNCTION__, m_pMeshBuffer->getReferenceCount());
  ::OutputDebugString(sMsg);
  
  ASSERT(FALSE);
}
 

The wierd thing is, that i drop and load meshes into the scene node dynamically and it is random whether the mesh is dropped succesfully or not. The output string then shows that the reference count of the mesh is 1, so something still has a reference to it. I am quite sure that i never grab the mesh any where in my code. Has anybody experienced something similar? Or maybe know where I should look?

One other thing I would like to know is, reading this topic I see salvik said the following:

The texture cache automatically holds on to all loaded textures until you manually remove them or until the driver is reset. This is done for the exact reason you mentioned: multiple materials and meshes may use the same texture. By holding onto them, time is saved since the GPU never has to reload the textures.

I have set a texture on my scenenode and a shader, do i understand this correctly that even though all scenenodes which use the a particular texture have been dropped you still need to remove the texture manually?

[hybrid]

Yes, both meshes and textures are hold in a separate cache. This makes it easy to access textures by their names, and allows to use meshes in several scene nodes without recreating them all the time. You have to remove those explicitly when you're done with the mesh, but not with the whole app.