How is a memory budget determined?

Without getting too deep in techincals, what's the big idea?

How accurate can you get? What's you standard procedure? How does this fit into your project planning?

 

((this is an opinion.

Without source code access you can run your most resource-intensive scene and multiply memory use by some factor.
I.e. through experimenting, and adding safety margin afterwards.

With source code access you can calculate amount of memory allocated with byte precision, the thing is as far as I can tell, nobody really does this these days, and memory requirements are very approximate. Meaning they likely run it on multiple machines, and set computer which doesn't freeze due to hitting swap as a minimum.

 

@BIGTIMEMASTER, unless you are experienced in memory management and optimization, process of memory analysis is at profiler level. Then you look for an optimization, if required.

Just like having 3D models and textures, once done, you optimize them, when are too big, in terms of space.
This for example, where compression for images come into play.
When experienced, you can estimate that model x with textures y, will take z amount of memory.

Similar with a game. But really need to profile.

 

I do fermi estimation based on the content (generally story and genre define the scope) of the project and a similar looking project. It's basically "number of assets x size/details of assets" and cobbling a scene with quick placeholder with the same technical weight to look for easy gotcha. Nothing complicated.

 

I use a far more primitive approach. I have a minimum spec machine I'm targeting, and I test builds against it. If/when I get unacceptable performance on this machine, then I investigate and take action. If I get acceptable performance then I focus my energy elsewhere.

 

This is how I handle things as well. I put together a machine where I have a low-power GPU to test against (I use a GTX 660) and an integrated chip, with a hard memory limit of 4gb, and a rip roarin' super powered i3-3220.

My low-spec target is pretty damn low spec, really, so I recommend maybe putting together something a bit beefier than this is you're trying to hit something other than "every PC that can run a game."

 

This reponse reminds me that I still need to take the time to set up my Xbox One S. I bought it with the intention of using it for developing console games but also for the purpose of determining if my games will run well on low-end hardware.

https://docs.microsoft.com/en-us/windows/uwp/xbox-apps/system-resource-allocation

 

I've only seen the term memory budget pop up a few times. Due to the word "budget" being used specifically, I had an idea that maybe there is some methods to estimate memory needs while still in planning stages. But it sounds like, at least based on answers so far, that iterative testing is about all you can do?

 

The best you can hope for is the most vague of estimates, but even those are subject to change well throughout development.

 

Two things.

First of all, as people here have already mentioned, there's some limit of the amount of memory your whole game has to run in. If you're using too much it won't run on your players' machines so you need to cut back. This is what matters for most indie teams.

Secondly, as your team grows and you have different sub-teams working on different parts of the game, and testing things separately from one another, you might want to pre-budget your overall memory resources so that each team knows how much they're allowed to use. You can't have everyone just do a build and check the total because you don't know whether others are going to increase (adding stuff) or decrease (optimise stuff) their usage with future work. So the idea is to come up with a budget for each team to work towards, and to shuffle the budget around as each team gets a clearer idea of what they need.

As an example of how that might play out, a level design team might get told a scene has a certain memory budget. They use this to determine how many resources of what size they're able to use - textures, audio, etc. (Or they just build stuff and iteratively tweak internally, because that's not too hard if you've got tools which can measure this stuff easily.) Later, a different team might come in under budget, allowing the level team to increase some texture resolutions or add extra sound effects or whatnot. Or, if something elsewhere is unable to reach its budget, the level team might be able to lower theirs by taking things out, lowering resolutions, or whatnot.

Note that this isn't just a memory thing. If you count your frame times in milliseconds then that's a resource that can be budgeted, too. Each tick in your game gets 16 or 33 milliseconds of CPU and GPU time, and you can profile how long different things take on each.

I'll repeat because it's important: this all relies on having effective tools to measure these things.

 

From what I gather, rather than "we need to spend X on Y" it's "you're allowed to spend up to X on Y, otherwise we need to revise our plan". It's just pre-agreed targets to prevent people from stepping on each others' feet in a large team, and to use as a baseline when communicating.

 

It would largely apply to consoles.
For example, PS4 has 8 gigabytes of memory total, and that's unified memory used by both CPU and GPU.
I don't think PS4 has a swap file.

 

That was my next question. This sounds like a thing where you could make a more useful estimate when you know all your users will be using the same hardware.

 

Well then the budget is the "min specs" you are targeting, that's why you have min spec and recommend specs in game sheet. They are rough estimation, you know you can have x characters with x polygon with x shader complexity ROUGHLY. You know a ps2 game won't have all character walking with 4k textures and 50 000 tris just for the face. You can try to do back of envelope calculation to have theoretical limits (1 uncompressed 4k textures is 64mo, how many do you realistically need, and how much you can fit in a 4gb ram?) and you can do benchmark to evaluate that rough capacity.

But advanced trickery mostly happen in the optimization phase, so you need to profile along 4 general metrics (which may have sub system metrics):
- memory (ram, stockage)
- bandwidth (how fast you access things in memory)
- compute power (cpu and/or gpu)
- "logistic" (ie in which order to do the thing above to save stuff)
3 of them are basically just "available resources >= size x number of stuff"

it's not that complicated, the complication is really just the need of the project, eventually to know the architecture structure of hardware, the overhead of engine and of the os, and finding ingenious way to balance when you go over budget (which is the hard part). Porting is where budgeting become a master art, especially downporting, because you try to fit a budget to something that have different hold of resources.

Here is an example if you want get what is the trickery:
https://threader.app/thread/1076765876148490240
Hint: it's profiling profiling and profiling.

 

There's no hand-waving or magic involved. It's straightforward and precise.

• You identify the platforms the game must run on, such as a Nintendo Switch, iPad mini 2, or Windows 10 PC with 2 GB VRAM and 8 GB system RAM (e.g., your minimum spec listed on Steam).
• For each platform, identify how much memory the OS allows the game to access, which may be unified or may be separate for system RAM and VRAM.
• Set limits for each platform. For example, if your platform has 1 GB VRAM and you want to avoid swapping in and out during a level, all textures for that level will need to total 1 GB or less when decompressed into whatever format the platform stores in VRAM.

You can profile for sanity checks afterward, and to make sure you stuck within your budget, but the first step is just looking up the specs and doing the math.