Data structures for tile-based (deferred) rendering Tiled rendering is used in modern mobile GPU architectures to increase the coherency of memory access by subdividing image space into a regular grid of small (e.g., 32x32 pixel) tiles. Information is scarce on the types of data structures used to track the primitives that are associated with each tile, considering that arbitrarily many primitives may overlap any given tile. 

From the perspective of a driver developer, what data structures are commonly used to represent the primitive sets that belong to a tile, and are such structures dynamically allocated/resized according to the geometry that overlaps a particular tile?
That blog post that John mentions is a pretty good start (if I do say so myself!), but there's a bit of extra detail that might be helpful.

For the PowerVR architecture, the intermediate data structure -- variously called the primitive list or parameter buffer (PB) -- that stores the per-tile data, after all vertex shading and the tiling process is complete, is actually mostly generated and managed by the hardware, rather than the driver.

The PB's in-memory structures are physically split into two. First, blocks of transformed vertex data, including vertex attributes. The blocks are compressed, and as you can imagine they're just packed and compressed floating point data for the most part. The second in-memory structure is the tiling data, which is effectively a list of lists.

The top level list in that data structure is called a region, and it can encode a set of tiles rather than single tile at a time, for a given primitive block. A region is therefore a set of locations of screen tiles, tile states, and then a list of the compressed blocks that hold geometry in that region. Regions are what the rasteriser works on, and you can imagine that empty tiles are just automatically skipped, although there's a good reason in some cases for the rasteriser to visit empty regions.

The memory the GPU uses for the PB is dynamically allocated in all modern PowerVR implementations. A pointer to that memory is provided by the driver, and the driver, with the GPU's help, will size it as required. That mechanism is a tradeoff between having to reallocate frequently and minimising the amount of allocated PB space.

Modern GPUs try really hard to minimise memory indirection, but walking the PB to feed the rasterisation stage is one of those cases where it's really difficult and there's no other choice. Thankfully the pointer chasing wraps up large blocks that cache well and are streamed into the core.

Other architectures don't work exactly the same as PowerVR, because part of the reason the PB is the way it is in our architecture is to help the fully deferred pixel shading concept we implement, but the general concept applies to all other tilers in the mobile space that I'm aware of.