8 replies to this topic

[geon]

Hi.

I am a bit curious on memory managent on game consoles. Since they traditionally are pretty limited and have no hard drive to swap to... How is it genarally taken care of?

(Note that I will probably never touch the code of anything console-related. I'm simply curious. I read this article, wich I found interesting, but not really informative.)

If I would code for the PC, I could forget about memory limitations and just tell the user he/she need so-and-so much free disk space for swapping. If I decided to do it properly, I could be implemet some memory pooling where I find it useful and notify the user when the memory is getting full.

But neither of this is practical for a console. Lets say I want to load another texture for the level I'm in. If the memmory is finnished, should I try to automatically kick something old out, and load it happily, somehow NULL-ing the freed resource?

Or is it as simple as making shure everything will just fit in the avaiable memory?

[jff_f]

I never programmed for other that PC. But as far as I understand since you are the *only* application running on the console (except maybe some sort of operating system)... You can access all the memory (again except the OS private data). You should still have access to malloc/free and new/delete since they are usually implemented as system calls (maybe something else) in the operating system on the platform.

I think that writing your own memory manager and get the maximum of the memory at once is more efficient because memory allocation and deallocation needs to work in the kernel mode (Ring 0 if you know how memory management works on a PC). Switching between the different modes takes a long time and that way you need only to switch once (well you switch to the kernel mode to the user mode). Since you get all what you need (or whatever is available) it's faster because your application then manages its own memory and doesn't need to switch to kernel mode.

On the consoles you can take all the memory available since you're the only app that will need to access the memory while running. Or at least you have control on them since you started them. I don't know how the consoles tends to manage/use the memory... like maybe the OS is kept somewhere else and you can access all the memory. And there might be hardware specific features or limitations.

Couple years ago I wanted to write a Game OS that could boot on a CD-ROM that way I could get the most performance out of a PC... but... it was too hard to make for me alone. I learned alot about things that may be useful later if I work on consoles... and I think efficient memory management would have been the hardest. Maybe you should do like I did and read on memory management on Operating systems since it's almost the same but malloc and free (hardware specific) are already done for you and you don't have to mess about the hardware specific to protect the OS and virtual memory... Only read through the memory allocation and deallocation algorithms. Then I guess that overloading the new and delete operators to work with this memory manager might me a good idea and use malloc and free for whatever is available with the hardware.

Using a memory manager you know if you have enough space to fit the textures and all the other ressources. If you don't take all the available memory, like you should do on a PC cause you'll get alerts of low memory, you can make a growable memory block. And you can make things even better and allow the memory blocks not to be contiguous. I can't remember if using realloc really gets a contiguous block of memory on the "hardware", because there are things like virtual memory on the PC. If you got the not contiguous blocks of memory you'll then need a way to link them and to make sure you don't write a ressource on more than one block because I don't think that any other library will like that. Then you use references and pointers exactly like you would be doing in normal C/C++. And make sure you use the overloaded new and delete operators you made.


That's about all I can write without giving a complete course on memory managers ;)... but all you need if somewhere... <hint> look in Operating system development tutorials there are plenty of ressources there on memory management. </hint>.



JFF

[.oisyn]

A modern console isn't that very different from a PC in terms of game programming. You simply have a somewhat tighter budget to work with, so memory usage is usually carefully planned out. Different subteams are assigned a specific memory budget, which sometimes mean you'll have to use some lower res textures and such to make it all fit.

[geon]

Thanks a lot!

[Alex]

AFAIK the mem management depends on which console you're runing on. The xbox trys to be a kinda pc. So it's relatively easy to port to (especially as the old box has a build in HD, with the HD optinal in the new xbox things get more complicated). I never coded ps2 myself but our game was ported to ps2 and I often talked to the programmers doing that. On the ps2 you get pretty low level control for most things. Normally you only run one thread(dunno if the ps2 actually supports multi threading, but threads could be simulated if desired) and have pretty much total control over memory. That allows you for example to handle deallocation differently. You can set a marker on your heap (from here on all new allocations are specific to the current game level) and when unloading the level you simply discard everything on the heap that is placed after that marker instead of releasing each resource individually. Typically the development kits will have more memory than the real deal console for debugging purposes. So the team creates estimated memory budgeds and develops using that. Eventually, everything is sqeezed into the memory available on the real console.

Alex

[geon]

So if I ask "What do you do when you run out of memory?", the answer should be "You don't!"?

[jff_f]

geon said:

So if I ask "What do you do when you run out of memory?", the answer should be "You don't!"?

The better answer is... "You shouldn't!"... because you write your game with a memory budget... you HAVE to keep below this boundary and do all you can to stay within it. Because if you need more memory than what is available... you won't be able to store anything and the game will crash or may be handled any other way, but the thing is that this won't work.

The way to handle this is up to you. You can use white texture with red lines on it to see what texture didn't load because there were no space. You can use a special mesh to show you that an object didn't load. And it may help you debug, but these takes some space in the memory. I don't rely know how the consoles SDK works but I think that there is a way to connect and debug remotely or to send data in any way.... and you might use that to send any information needed to manage those memory problems. You can also only show debug info in a console or directly on the screen.

You might also include how much memory you use in your debugging info so you know how much memory is used and you can then find where you can reduce it.


And remember that using hard drive is juste like any IO... they take time. So if you need to swap to a hard drive because you're game contents doen't fit in memory and that there exist a way you can do without (like if the memory you use is not much more than what is available) try doing thing another way this might keep your game more responsive to more important things like user input and maybe you'll achieve a better framerate.


Ok... that's about all I have to say right now on the subject.

[.oisyn]

jff_f said:

And remember that using hard drive is juste like any IO... they take time. So if you need to swap to a hard drive because you're game contents doen't fit in memory and that there exist a way you can do without (like if the memory you use is not much more than what is available) try doing thing another way this might keep your game more responsive to more important things like user input and maybe you'll achieve a better framerate.

Usually these things are solved using streaming. The data is cooked ready-to-go on the disc, and things are streamed in just before the game needs them. But, streaming and especially seeking on a DVD-like medium is much slower than from harddisk, so the temporary title area on the xbox harddisk can be handy to setup things in advance.

[geon]

jff_f: Yes, placeholder textures/models would be a nearly-acceptable solution. With some luck, no one will notice, and at least the game won't crash.

.oisyn: Hmm. Using the harddrive as a cache for an optical disc. Never thought of that.


I came to the conclusion, that much of the memory problems are up to the content creators to handle. The level designers will have to divide each level into sectors small enough to fit in memory. AND to make sure only one sector is visible at any time.