Hacker News new | ask | show | jobs
by armada651 881 days ago
> How to workaround too little RAM problem? Let’s load pixel graphics if player is far away and call it mip mapping

Hold up, mip mapping is not a way to save RAM in fact it consumes more RAM because not only do you need to have the full-size texture in RAM you also need to keep smaller copies in RAM.

What it does save on is memory bandwidth, because you don't need to sample from the full-size texture for objects that are far away. And it improves visual quality, since you can use expensive scaling algorithms to produce high-quality downscaled copies.

2 comments

>Hold up, mip mapping is not a way to save RAM in fact it consumes more RAM because not only do you need to have the full-size texture in RAM you also need to keep smaller copies in RAM.

While that's how it's mostly used today, mipmapping refers to storing scaled-down versions of the same texture along with the original texture. You don't have to load all of them to RAM (or VRAM). You can simply store the mipmaps on a hard drive, and only load the required mip levels to the GPU, thus saving VRAM. This way, you are using mipmaps as texture LODs. Think about satellite images of Google Maps.

>What it does save on is memory bandwidth, because you don't need to sample from the full-size texture

Not exactly. It does save memory bandwidth, because you're sampling less texels and reducing cache misses, not because you're sampling from a smaller texture. You're simply not downscaling the texture on the fly, instead using precalculated downscaled pixel values.

Mip mapping was originally developed neither for bandwidth nor memory reasons, but for texture filtering.
in early games it was a metod to save RAM too, for a short time but it did. Because you didn't have to store all mip map parts in the RAM
How does storing more copies of the same texture save ram?

Of course one can drop the higher resolution textures, but AFAIK that technique came long after mipmapping, as it requires high cpu-to-gpu bandwidth, which wasn't there in the earlier days.

Right. Mipmapping is different than simply using lower levels of detail textures. Mipmapping is when you store the full level of detail plus progressively lower levels of detail (always adding up to 33% more data) so that the correct LOD texel can be looked up depending on the required rendering detail. You're using more memory for higher quality (and sometimes faster) rendering.
What is it when you have the detail texture loaded in such a way that you can say "get every second byte (or whatever)" to get the half size, and so on?

IIRC some CPUs were good at that kind of memory access, but most were not.

Some implementations of mipmapping store a single medium-resolution image and either sample fewer pixels or duplicate neighboring pixels when drawing. You don't need extra memory for that. Literally just mapping a subset of the pixels from the texture stored in memory.

When enough pixel duplication occurs you may want to enqueue a request for a higher resolution texture to be loaded into memory and let the resource pool decide. You can see this in effect in some older games where you're able to "outrun the horizon/frustrum" so to speak or when too many objects spawn and the level of detail is terrible for a while until the game catches up. Otherwise this is just a most-recently-used cache. Mipmapped textures can either be many prescaled static copies on disk or precomputed from the single full resolution asset on disk while loading a level.

That's just level-of-detail on top of mipmapping. Mipmapping requires strictly more textures for the same level of detail.