Partially Resident Textures
AMDs latest GPUs have one interesting new feature: Partially resident textures, PRT for short are a new way to handle textures too large for the graphics memory.
But let’s start at the beginning: Up till now GPUs didn’t have a memory management unit (MMU), so all the data for rendering had to be present in the graphics memory. That’s especially problematic for textures, on the one hand you want high resolution textures to create a world with lots of detail, on the other hand you see most of the scene most of the time from a larger distance. While you might see all details eventually, you can never see everything at once: your screen size is too limited (and tiny compared to the amount of textures in large virtual worlds like games).
Megatexturing or virtual texturing as it’s used in ID Softwares latest shooter Rage is exploiting the fact, that you can’t see all the details at once and manages to handle around 20GB of textures – or better, one gigantic texture. It analyzes which parts are needed and swaps those parts in. All of this is done in software as a CPU or CUDA implementation (depending on the users settings and the platform).
Partially resident textures promise to give the programmer a simple way to use gigantic textures but this time the detection of missing data and the fetching will be done by the MMU of the GPU. John Carmack already announced, that Doom 4 will get optional support for this technique.
AMD has published a demo that presents this technique, the demo is written in OpenGL using an extension. No Direct3D support was announced yet, but I guess it will become a part of one of the next DX versions. The OpenGL extension used internally by AMD was announced, but it is not yet public.
This means that the most interesting questions are still open: What happens in case of missing data? Does the pipeline stall or will data of a lower MipMap level be used? The last option will imply, that MipMapping will be mandatory but also, that it is suitable for real-time applications and behaves analog to ‘software’ megatexturing. On the other hand would scientific calculations – via shaders or via OpenCL – benefit from PRT as well but only if the pipeline would stall – MipMapping arbitrary data doesn’t make sense in general! So maybe the programmer can choose an ‘operation mode’ for PRT, but will that be exposed as a new API or as a new texture fetch command for GLSL? I would bet on the API solution, making this fixed per texture is probably easier to implement. But if the pipeline stalls anyway, using the MMU for large data could also be interesting for other buffers beside textures…
NVidia has also announced MMUs in there next GPU generation Kepler but has given even fewer details about that.
I hope that the long wait for the OpenGL extension is a good sign and AMD is already talking to NVidia to create a unified extension, the Kepler GPUs are just around the corner…
Update (3/21/2012): AMD released additional informations about the OpenGL extension (AMD_sparse_texture).