From reading the XB360 Predicated Tiling whitepaper, I've learnt the following:
- The alpha kit "emulated" predicated tiling - though it did so with slightly different tile-size restrictions (i.e. how tile boundaries are aligned within the render target/back buffer). It also did so without actually performing any predication! so that 2 tiles performed at half the speed of 1 tile, etc.
- Predicated tiling in Xenos works by having the GPU render all commands on the first tiling pass (even if they don't fit into the first tile) - this first pass works out the extents (2D coordinates) of the draw commands. This only applies to vertices. Pixels are not "overdrawn".
- The Z-pass is actually separate from the "tiling prepass" - but the data for the two can be consolidated. A discussion of this isn't in the whitepaper (it's fairly old).
- A special "patch-up" process runs on a CPU core, which edits each draw command's "predicate instruction" in the command buffer with the set of extents generated by the first tiling pass - this is not something done by the GPU. The edit simply entails noting which tiles the draw command affects, which is a process of comparing the draw command extents (generated by the first pass) against the tile coordinates.
- Triangles that overlap multiple tiles will be "clipped" to each tile - much as triangles are clipped to a normal viewport. This clipping will incur a small overhead (not quantified yet), and adds in to the overhead of predicated tiling.
- Xbox Procedural Synthesis isn't able to work directly with automatic predicated tiling. Automatic predicated tiling is where the developer can just say "render with tiles" and predicated tiling happens. To get XPS and tiling to work together, the developer has to perform their own tile extents testing and predication - it becomes a fully-manual tiling process, basically. Part of the XB360 D3D command set available to the developer is the predication instruction and the 2D extents capture, so it's not a nightmare. But it's certainly something for developers to get to grips with.
- Memexport also requires manual tiling, otherwise memexport will perform duplicate writes to memory, once per tile.
In general, I think a lot of the issues with predicated tiling will be ameliorated by the "multi-pass" nature of 3D rendering. e.g. during shadow calculation or tessellation, the entire 48 pipelines are able to process vertex data since there is no pixel shading - so that the vertex overhead associated with tiling (around 2x) is easily within the capabilities of Xenos.
Simple examples where manually-predicated tiling can occur are rendering the gun in an FPS or the HUD, since these items are static or nearly static in the 2D space of the screen.
So, all in all, predicated tiling in XB360 seems to be operating at a fairly crude level. The more advanced features of XB360 (XPS and memexport) require that the developer performs tiling themselves.
Having said that, it also seems that M$ intended that (automatic) predicated tiling became the baseline. With a "simple" 3D engine M$ shows that only a few high level D3D calls are required to activate predicated tiling - for the developer it's practically transparent. Care needs to be taken in fitting screen-render tiles plus any other render targets (that are created concurrently) into EDRAM. As soon as the 3D engine gets into advanced techniques like stencil shadow volues or post-processing, though, automatic predicated tiling is no longer a fire and forget concept.
I actually think (automatic) predicated tiling will come into play for emulation of XBox 1 titles (the whitepaper includes an analysis of tiling overhead based on over 150 XBox 1 titles) giving them 4xMSAA and 720p "for free". In these titles, sheer brute force presumably means that the overheads associated with automatic predicated tiling are not material. Whereas I think the complexities of newer 3D engines for "next gen" games will prevent developers from simply "flicking the switch" to enable predicated tiling. The limits on XPS, particularly, seem to fly in the face of "easy predicated tiling".
Since I'm not a developer, my characterisation of the cut-over between simple engines that are compatible with automatic predicated tiling and manually implemented tiling is not well-informed! It could be that practically all 3D games require at least some manual tiling, and perhaps all XB360 games require manual tiling. I'm guessing that XBox 1 games are a trivial workload for XB360, so that any mismatches caused by automatic predicated tiling (e.g. rendering an entire frame's special effects, such as shadows or depth of field, thrice instead of once!) are not deal-breakers.
All of which, I hope, sheds light on why early XB360 games have seemingly used "lower resolutions" to avoid tiling, rather than to get sucked into the complexities of manual tiling - even if they only apply to special effects.
Jawed