🔒 Locked

On SetTexture reference count behaviour

Started by Krohm Jan 6, 2007 at 9:20 AM 5 replies 2.6k views

Original Post

Jan 6, 2007 at 9:20 AM

Today, overlooking the docs, I read:

Quote:
Texture resources Note: The IDirect3DDevice9::SetTexture method increments the reference count of the texture surface being assigned. When the texture is no longer needed, you should set the texture at the appropriate stage to NULL. If you fail to do this, the surface will not be released, resulting in a memory leak.

Firing the search with "SetTexture" on MSDN didn't worked as expected while firing google with "IDirect3ddevice9 SetTexture NULL behaviour" returned this interesting forum thread. From here, I see that textures reference counts (as well as other) are decremented on change so calling SetTexture(..., NULL) seems to be necessary only for the "last resource". Is this correct? While I understand the need to avoid destroying objects while they are being used, this seems a bit overkill to me. Is this going away with D3D10? Is this going to be documented in the appropriate pages? Does this apply to every resource created with a Create*** call?

Krohm

Jan 8, 2007 at 3:06 AM

I agree. I guess I'll spend some time tracking the resources.
Thank you!

EDIT: looks like Vertex Declarations does not follow this rule. SetVertexDeclaration(NULL) will pop a warning so there's no way to "unbind" the "last resource".

[Edited by - Krohm on January 8, 2007 5:06:57 AM]

jollyjeffers

Jan 8, 2007 at 5:43 AM

I don't think it's overkill - might take a little getting used to, but it's not too much hassle [smile]

Consider the fact that D3D has a deep pipeline and that you calling:

SetTexture(x) DrawPrimitive(..) SAFE_RELEASE(x)

might not happen in the order you expect it - your application is likely to release its interest in the texture BEFORE the draw call that uses the texture has been used. If the pipeline is 2-3 frames deep and you're close to filling it then it might well be a couple of iterations of your entire application loop before the resource is actually unneeded and out of the command queue...

By and large D3D10's behaviour is the same as D3D9's but ISTR there are a few changes detailed in the documentation. The only part that comes to mind (don't have my docs to hand) is the FX10 "handles" that appear as objects but aren't reference counted...

hth
Jack

Krohm

Jan 8, 2007 at 5:55 AM

Quote:
Original post by jollyjeffers
might not happen in the order you expect it - your application is likely to release its interest in the texture BEFORE the draw call that uses the texture has been used. If the pipeline is 2-3 frames deep and you're close to filling it then it might well be a couple of iterations of your entire application loop before the resource is actually unneeded and out of the command queue...

Yes, I understand. It does probably have to deal with the fact D3D objects are "real objects" rather than handles to internal structures.
If I think at the D3D runtime using the same application structures I see this makes sense and is definetly needed even if the commands are processed in-order. If this is really what happens I don't know but it looks reasonable considering the behaviour.

Quote:
Original post by jollyjeffers
By and large D3D10's behaviour is the same as D3D9's but ISTR there are a few changes detailed in the documentation. The only part that comes to mind (don't have my docs to hand) is the FX10 "handles" that appear as objects but aren't reference counted...

That's great to know! Thanks!

don

Jan 8, 2007 at 12:35 PM

This has changed for D3D10. If you release a texture that is selected into a stage, the texture for that stage is set to NULL by the runtime and the texture is destroyed. You don't have to explicitly set the stage's texture to NULL.

Krohm

Jan 9, 2007 at 1:45 AM

Good to know. I think I'll check with PIX anyway. Dumping a few frames should be enough.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.