Partially Resident Textures: Not Your Father’s Megatexture

John Carmack’s id Software may not be the engine licensing powerhouse it was back in the Quake 3 days, but that hasn’t changed the revolutionary nature of his engine designs. The reason we bring this up is because there’s a great deal of GPU technology that can be directly mapped to concepts Carmack first implemented. For id Tech 4 Carmack implemented shadow volume technology, which was then first implemented in hardware by NVIDIA as their UltraShadow technology, and has since then been implemented in a number of GPUs. For id Tech 5 the trend has continued, now with AMD doing a hardware implementation of a Carmack inspired technology.

Among the features added to Graphics Core Next that were explicitly for gaming, the final feature was Partially Resident Textures, which many of you are probably more familiar with in concept as Carmack’s MegaTexture technology. The concept behind PRT/Megatexture is that rather than being treated as singular entities, due to their size textures should be broken down into smaller tiles, and then the tiles can be used as necessary. If a complete texture isn’t needed, then rather than loading the entire texture only the relevant tiles can be loaded while the irrelevant tiles can be skipped or loaded at a low quality. Ultimately this technology is designed to improve texture streaming by streaming tiles instead of whole textures, reducing the amount of unnecessary texture data that is streamed.

Currently MegaTexture does this entirely in software using existing OpenGL 3.2 APIs, but AMD believes that more next-generation game engines will use this type of texturing technology. Which makes it something worth targeting, as if they can implement it faster in hardware and get developers to use it, then it will improve game performance on their cards. Again this is similar to volume shadows, where hardware implementations sped up the process.

In order to implement this in hardware AMD has to handle two things: texture conversion, and cache management. With texture conversion, textures need to be read and broken up into tiles; AMD is going with a texture format agnostic method here that can simply chunk textures as they stand, keeping the resulting tiles in the same format. For AMD’s technology each tile will be 64KB, which for an uncompressed 32bit texture would be enough room for a 128 x 128 chunk.

The second aspect of PRT is managing the tiles. In essence PRT reduces local video memory to a very large cache, where tiles are mapped/pinned as necessary and then evicted as per the cache rules, and elsewhere the hardware handles page/tile translation should a tile not already be in the cache. Large tomes have been written on caching methods, and this aspect is of particular interest to AMD because what they learn about caching here they can apply to graphical workloads (i.e. professional) and not just gaming.

To that end AMD put together a technology demo for PRT based on Per-Face Texture Mapping (PTEX), a Disney-developed texture mapping technique that maps textures to polygons in a 1:1 ratio. Disney uses this technique for production rendering, as by constraining textures to a single polygon they don’t have to deal with any complexities that arise as a result of mapping a texture over multiple polygons. In the case of AMD’s demo it not only benefits for the reasons that Disney uses it, but also because when combined with tessellation it trivializes vector displacement, making art generation for tessellated games much easier to create. Finally, PRT fits into all of this by improving the efficiency of accessing and storing the Ptex texture chunks.

Wrapping things up, for the time being while Southern Islands will bring hardware support for PRT software support will remain limited. As D3D is not normally extensible it’s really only possible to easily access the feature from other APIs (e.g. OpenGL), which when it comes to games is going to greatly limit the adoption of the technology. AMD of course is working on the issue, but there are few ways around D3D’s tight restrictions on non-standard features.

Tahiti: The First Direct3D 11.1 GPU Display Tech: HD3D Eyefinity, MST Hubs, & DDM Audio
Comments Locked

292 Comments

View All Comments

  • chiddy - Thursday, December 22, 2011 - link

    Ryan,

    Thanks for the great review. My only gripe - and I've been noticing this for a while - is the complete non-mention of drivers or driver releases for Linux/Unix and/or their problems.

    For example, Catalyst drivers exhibit graphical corruption when using the latest version (Version 3) of Gnome Desktop Environment since its release before April. This is a major bug which required most users of AMD/ATI GPUs to either switch desktop environments, switch to Nvidia or Intel GPUs, or use the open source drivers which lack many features. A partial fix appeared in Catalyst 11.9 making Gnome3 usable but there are still elements of screen corruption on occassion. (Details in the "non-official" AMD run bugzilla http://ati.cchtml.com/show_bug.cgi?id=99 ).

    AMD have numerous other issues with Linux Catalyst drivers including buggy openGL implementation, etc.

    Essentially, as a hardware review, a quick once over with non-Microsoft OSs would help alot, especially for products which are marketed as supporting such platforms.

    Regards,
  • kyuu - Thursday, December 22, 2011 - link

    Why in the heck would they mention Linux drivers and their issues in an article covering the (paper) release and preliminary benchmarking of AMD's new graphics cards? It has nada to do with the subject at hand.

    Besides, hardly anyone cares, and those that do care already know.
  • chiddy - Thursday, December 22, 2011 - link

    And I guess that AMD GPUs are sold as "Windows Only"?

    Thanks for your informative insight.
  • MrSpadge - Thursday, December 22, 2011 - link

    There are no games for *nix and everything always depends on your distribution. The problems are so diverse and numerous.. it would take an entire article to briefly touch this field.
    Exagerating, but I really wouldn't be interested in endless *nix troubleshooting. Hell, I can't even get nVidia 2D acceleration in CentOS..
  • chiddy - Thursday, December 22, 2011 - link

    You have a valid point on that front and I agree, nor would I expect such an article any time soon.

    However, on the other hand, one would at the very least expect a GPU using manufacturer released drivers to load a usable desktop. This is an issue that was distro agnostic and instantly noticeable, and only affected AMD hardware, as do most *nix GPU driver issues!

    If all that was done during a new GPU review was fire it up in any *nix distribution of choice for just a few minutes (even Ubuntu as I think its the most popular at the moment) to ensure that the basics work it would still be a great help.

    I will have to accept though that there is precious little interest!
  • Ryan Smith - Thursday, December 22, 2011 - link

    Hi Chiddy;

    It's a fair request, so I'll give you a fair answer.

    The fact of the matter is that Linux drivers are not a top priority for either NVIDIA or AMD. Neither party makes Linux drivers available for our launch reviews, so I wouldn't be able to test new cards at launch. Not to speak for either company, but how many users are shelling out $550 to run Linux? Cards like the 7970 have a very specifically defined role: Windows gaming video card, and their actions reflect this.

    At best we'd be able to look at these issues at some point after the launch when AMD or NVIDIA have added support for the new product to their respective Linux drivers. But that far after the product's launch and for such a small category of users (there just aren't many desktop Linux users these days), I'm not sure it would be worth the effort on our part.
  • chiddy - Friday, December 23, 2011 - link

    Hi Ryan,

    Thanks very much for taking the time to respond. I fully appreciate your position, particularly as the posts above very much corroborate the lack of interest!

    Thanks again for the response, I very much appreciate the hard work yourself and the rest of the AT team are doing, and its quality speaks for itself in the steady increase in readers over the years.

    If you do however ever find the time to do a brief piece on *nix GPU support after launch of the next generation nVidia and AMD GPUs that would be wonderful - and even though one would definately not buy a top level GPU for *nix, it would very much help those of us who are dual booting (in my case Windows for gaming / Scientific Linux for work), and somewhat remove the guessing game during purchase time. If not though I fully understand :-).

    Regards,
    Ali
  • CeriseCogburn - Thursday, March 8, 2012 - link

    Nvidia consistenly wins over and over again in this area, so it's "of no interest", like PhysX...
  • AmdInside - Thursday, December 22, 2011 - link

    I won't be getting much sleep tonight since that article took a long time to read (can't imagine how long it must have taken to write up). Great article as usual. While it has some very nice features, all in all, it doesn't make me regret my purchase of a Geforce GTX 580 a couple of months ago. Especially since I mainly picked it up for Battlefield 3.
  • ET - Thursday, December 22, 2011 - link

    The Cayman GPU's got quite a performance boost from drivers over time, gaining on NVIDIA's GPU since their launce. The difference in architecture between the 79x0 and 69x0 is higher than the 69x0 and 58x0, so I'm sure there's quite a bit of room for performance improvement in games.

    Have to say though that I really hope AMD stops increasing the card size each generation.

Log in

Don't have an account? Sign up now