Page Allocation Details

This step actually occurs before the shadow map rendering step (see The global map of the rendering). However, it will be easier if we first take a look at how the virtual shadow map is rendered.

Let’s start with a question we left in the previous chapter:

image
only pages 37, 43, and 47 have been marked as 'valid'

So the question is:

Why are the MIP 6 and MIP 7 in View 1 marked as "valid"?

Generate pages from pixels

This is done by a pass called GeneratePageFlagsFromPixels. This pass takes the gbuffer as input, and calculates the best mip level for each pixel. These pixels vote for the best mip levels. In the cube example, they voted for mip levels 6 and 7 for view 1.

image

This image chooses one pixel in the middle of the cube, and shows how it calculate the final mip level:

  • Project that into shadow space and counts the pixel num in mip 0
  • Find the best mip level with MipLevel=floor(log2(Footprint))MipLevel = floor(log_2(Footprint))

Physical page allocation

Now let’s step behind and think about another question

Who decides this virtual page should be mapped into that area of the physical page texture?
image

This is accomplished through several passes:

  • GeneratePageFlagsFromPixels: This pass determines the number and type of pages required and writes the result to the PageRequestFlags buffer.
  • Allocate new page mappings: This pass handles the allocation process and writes the data to the PhysicalPageMetaData, PageTable, and PageFlags buffers.
  • The next two passes deal with flags and mapping between mips, but we can skip these for now.
  • Finally, the initial physical pages pass performs the actual cleanup of mapped areas in the physical page pool texture.
image