• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Naruto-kun

Memory leak despite calling Release

6 posts in this topic

Hi guys

 

I have a bit of a problem. I created a render to texture system for blending certain textures together but despite my releasing those objects when I finish with them in the program (I don't release at shutdown, I release at the end of the cycle as the render only happens on command), the video memory in use does not decrease. Call the cycle additional times and it increases. Since the program on its own uses a sizeable amount of memory, users are running into OOM CTDs at times.

 

Anyone got an idea on how to fix this?

Thanks

JB

0

Share this post


Link to post
Share on other sites

First of all, you need to double-check how you're measuring video memory in use.  That may well be giving you misleading information.

 

Then you need to check your objects lifetimes.  As D3D is COM-based, and as COM manages lifetimes by reference counts, this kind of problem is normally caused by something somewhere continuing to hold a reference to an object.  Finding what that something is may not be so trivial, however.

 

D3D11 provides the ID3D11DeviceContext::ClearState call, which will unbind all state from your context, so using this before you destroy your objects can help; in D3D11 an object bound to the pipeline (e.g via PSSetShaderResources) will cause the context to hold a reference to that object (see the documentation for the various Set calls) so calling Release on it's own won't be enough to reduce the reference count to 0 and cause the object to be destroyed.

 

Alternatively, and if ClearState seems too drastic (the intention behind it's design seems to be to just use it before final shutdown to release any such outstanding references) you can always unbind that object, e.g by binding a different object in it's place, or by binding NULL.

 

Another possible cause is that you have other associated objects that you do not destroy.  E.g you'll typically have a texture and one or more views (in your case a Shader Resource View and a Render Target View); if you Release the texture but not the view(s) (or the other way around) you'll leak.

2

Share this post


Link to post
Share on other sites

Measuring the video memory using NVIDIA Inspector.

 

IUnknown::Release returns 0 for every instance of every object I have in use. Will try the ClearState though.

 

As for the shader resource views, there I release the view and the Texture2Ds that get created. The render targets are different though. There I keep the render target view until shutdown but I always increase the reference count when getting the resource to copy to system memory and then I release that resource afterwards to drop the reference count back down to what I had originally for the render target view.

 

Thanks a bunch.

0

Share this post


Link to post
Share on other sites

Maybe not usefull, but I once looked for a similar cause for hours.

In the end I created two backbuffers by accident and only called release just once.

Good luck

0

Share this post


Link to post
Share on other sites


IUnknown::Release returns 0 for every instance of every object I have in use.

This is not an indication that the interface was released! Perhaps not even if you run Direct3D in debug mode - IIRC, debug mode has it's own reference counting mechanism, which is accessed via the debug layer, but it is not exposed in the return value of Release.

 

So if you are just calling Release() on each interface pointer until it returns 0, you are doing it wrong. You have to call Release as many times as you called AddRef, or any other function that caused the refcount to go up.

 

if you do call Release in a loop this way and it did actually return the remaining reference count, you would end up causing other interfaces that are shared from the same object to crash, since the reference count is usually a per-COM object value (it can be implemented per-interface, but the COM docs say you cannot make assumptions - you must always call Release EXACLTY as many times as you - or Direct3D - called AddRef).

0

Share this post


Link to post
Share on other sites

After running things through the debugger I have verified that I have released the objects as many times as they were created. Still despite using the ClearState and Flush methods the video memory usage does not go down.

 

Any other ideas?

0

Share this post


Link to post
Share on other sites

If Flush doesn't do anything, you probably still have some unreleased video resources that you create every cycle. Make sure you release all of the objects, not just the textures.

Also, this doesn't make sense to me, but I'm guessing this is where your problem is:

 

 


I always increase the reference count when getting the resource to copy to system memory and then I release that resource afterwards to drop the reference count back down to what I had originally for the render target view.

Normally, you do not need to call AddRef on any of those resources you're binding (or their views). The Set... methods do this themselves, and then they call Release when you call ClearState or the same Set methods with NULL. If you still have to call AddRef and Release yourself for some other reason, then you have to call Release a second time to actually get the resource to be fully deleted, because the first time you're only releasing the reference you allocated - but D3D still holds a reference from when the object was created.

Edited by tonemgub
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0