Virtual Texturing: Manage Residency, Feedback and Missing Pages

Separate virtual address space from physical storage

Virtual texturing divides texture content into pages and keeps only a selected working set in physical memory. A large logical texture therefore need not have all of its detailed regions resident simultaneously. Microsoft's tiled-resource documentation describes this distinction. [1] The implementation still needs storage, transfer bandwidth and a policy for deciding what to retain.

Software page tables and hardware sparse resources provide different implementation choices. Verify the supported resource and sampling behavior of the chosen path; the term virtual texture does not imply identical guarantees everywhere.

Distinguish requested detail from available detail

Sampling feedback reports which texture regions and detail levels a view wants. It does not mean that those pages are already available. Microsoft's sampler-feedback design explicitly separates desired mip information from the map used to clamp sampling to resident detail. [2]

Retain a valid coarse fallback and route unavailable fine-detail requests to it. Process feedback asynchronously, deduplicate requests and prioritize uploads. Account for the delay between observing demand, reading storage and making an upload usable. A sudden camera turn can reveal regions that the previous view never requested.

Worked example: reserve the cache before counting demand

Suppose an illustrative cache has 64 page slots, each consuming 64 KiB. Its page storage is 4 MiB. If 8 slots are reserved for required coarse fallback pages, 56 remain for the current fine-detail working set.

A view requesting 80 distinct fine pages cannot fit all of them into those 56 slots. At least 24 requests must remain at fallback detail, be deferred or be avoided through a coarser detail policy. Cycling all requested pages through the cache does not solve this capacity mismatch. These figures exclude page tables, feedback buffers, staging memory and allocation overhead; they are a capacity example, not a measured texture budget.

Make mapping updates and eviction safe

Publish a page-table mapping only when its data is ready for the draws that can use it. When reusing a physical slot, ensure earlier GPU work cannot still read its previous contents. Track page identity and generation so delayed requests or completions cannot accidentally update a slot belonging to another page.

Visualize requested, resident and fallback pages separately. Test fast travel, teleports and repeated movement between areas. Include filtering borders and all material layers in physical page accounting. Verify that the fallback remains usable during cancellations and upload failures.

Recognize pressure instead of hiding it

Sustained demand above cache capacity produces repeated eviction and loading, often visible as unstable detail. Epic's memory-pool documentation describes this behavior and the quality tradeoff of reducing requested detail. [3] Measure occupancy, missed requests, upload latency and useful residency together. More storage throughput cannot fix an undersized working-set budget, and a larger virtual resolution alone does not make the final image sharper.

Sources

• [1] Tiled Resources — Microsoft, Direct3D documentation.
• [2] Sampler Feedback — Microsoft, DirectX specification.
• [3] Virtual Texture Memory Pools — Epic Games, official documentation.