Memory management

Started by
3 comments, last by RobM 12 years, 1 month ago
When a game engine loads all its data, there will be a conversion process to, for example, create vertex and index buffers for meshes. Continuing that example, when the vertex/index buffers are created, the data that was loaded is no longer needed and so is freed.

If you create the vertex buffer in the default pool, how can our own-rolled memory managers reliably work out where that memory is? If it gets swapped out to system RAM due to the video card memory being fully committed, how do we track it? I would imagine if our memory management library is tracking things like game objects, etc, it would need to be aware that video resources might take up its space at some point.

Thanks
Advertisement
On the desktop, that's all information that is impossible to tell in the general case. You are sort of left hoping that the OS and graphics drivers are doing their best.

In mobile/console development, you have a lot more guarantees that the OS isn't going to page half your program out to disk, or another process allocate half the video memory out from under you.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]


I would imagine if our memory management library is tracking things like game objects, etc, it would need to be aware that video resources might take up its space at some point.

Take up its space? What do you mean?

If your own memory manager has requested a chunk of RAM from the OS already, that RAM can’t take “taken up” by anything else.

If you are referring to the possibility of that RAM being taken away from your possible future allocations (from the OS), the above reply applies. There is no way to measure how much RAM that ends up being.

If you want to print how much RAM your game is using, including those resources, the best you can do is make an educated guess based off what you expect the driver to be doing with that data (and it is very likely your guess will fall short).


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid


When a game engine loads all its data, there will be a conversion process to, for example, create vertex and index buffers for meshes. Continuing that example, when the vertex/index buffers are created, the data that was loaded is no longer needed and so is freed.

If you create the vertex buffer in the default pool, how can our own-rolled memory managers reliably work out where that memory is? If it gets swapped out to system RAM due to the video card memory being fully committed, how do we track it? I would imagine if our memory management library is tracking things like game objects, etc, it would need to be aware that video resources might take up its space at some point.

Thanks


You can't.

D3D memory pools belong to the driver and the runtime, not to your program, and as soon as you load anything into any such pool it's game over. Not your property any more. You shouldn't need to be worrying about this; people have been creating and using default pool resources for well over a decade, the process is understood and drivers are robust and optimized. If you're concerned over interactions between your own memory manager and runtime/driver allocated memory then you may have a basic misunderstanding about how these things actually work.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

Thanks for the responses all.

I'm not concerned by how the video driver handles memory - I guess I was just wondering what happens when the video memory runs out and stuff gets shipped back onto system RAM. I guess it does just that.

Thanks

This topic is closed to new replies.

Advertisement