summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAlyssa Rosenzweig <alyssa.rosenzweig@collabora.com>2019-11-27 08:04:22 -0500
committerTomeu Vizoso <tomeu.vizoso@collabora.co.uk>2019-12-03 04:25:04 +0000
commit63cd5b8198cab169f8ba9f6250281a5f705fa6bb (patch)
treef6946d433ecf2f7bf14b0297c65dd6975115f942
parent6887ff4e79c7cb236c58a326159046a6406d21d5 (diff)
panfrost: Add information about T720 tiling
We've figured out most of the big pieces, and though it looks faintly like other Midgards, it's much simpler. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-rw-r--r--src/panfrost/encoder/pan_tiler.c47
1 files changed, 46 insertions, 1 deletions
diff --git a/src/panfrost/encoder/pan_tiler.c b/src/panfrost/encoder/pan_tiler.c
index af1e12e4805..98ef6827a80 100644
--- a/src/panfrost/encoder/pan_tiler.c
+++ b/src/panfrost/encoder/pan_tiler.c
@@ -36,7 +36,8 @@
* list". Finally, the rasterization unit consumes the polygon list to invoke
* the fragment shader.
*
- * In practice, it's a bit more complicated than this. 16x16 is the logical
+ * In practice, it's a bit more complicated than this. On Midgard chips with an
+ * "advanced tiling unit" (all except T720/T820/T830), 16x16 is the logical
* tile size, but Midgard features "hierarchical tiling", where power-of-two
* multiples of the base tile size can be used: hierarchy level 0 (16x16),
* level 1 (32x32), level 2 (64x64), per public information about Midgard's
@@ -152,6 +153,50 @@
* Once we have that mask and the framebuffer dimensions, we can compute the
* size of the statically-sized polygon list structures, allocate them, and go!
*
+ * -----
+ *
+ * On T720, T820, and T830, there is no support for hierarchical tiling.
+ * Instead, the hardware allows the driver to select the tile size dynamically
+ * on a per-framebuffer basis, including allowing rectangular/non-square tiles.
+ * Rules for tile size selection are as follows:
+ *
+ * - Dimensions must be powers-of-two.
+ * - The smallest tile is 16x16.
+ * - The tile width/height is at most the framebuffer w/h (clamp up to 16 pix)
+ * - There must be no more than 64 tiles in either dimension.
+ *
+ * Within these constraints, the driver is free to pick a tile size according
+ * to some heuristic, similar to units with an advanced tiling unit.
+ *
+ * To pick a size without any heuristics, we may satisfy the constraints by
+ * defaulting to 16x16 (a power-of-two). This fits the minimum. For the size
+ * constraint, consider:
+ *
+ * # of tiles < 64
+ * ceil (fb / tile) < 64
+ * (fb / tile) <= (64 - 1)
+ * tile <= fb / (64 - 1) <= next_power_of_two(fb / (64 - 1))
+ *
+ * Hence we clamp up to align_pot(fb / (64 - 1)).
+
+ * Extending to use a selection heuristic left for future work.
+ *
+ * Once the tile size (w, h) is chosen, we compute the hierarchy "mask":
+ *
+ * hierarchy_mask = (log2(h / 16) << 6) | log2(w / 16)
+ *
+ * Of course with no hierarchical tiling, this is not a mask; it's just a field
+ * specifying the tile size. But I digress.
+ *
+ * We also compute the polgon list sizes (with framebuffer size W, H) as:
+ *
+ * full_size = 0x200 + 0x200 * ceil(W / w) * ceil(H / h)
+ * offset = 8 * ceil(W / w) * ceil(H / h)
+ *
+ * It further appears necessary to round down offset to the nearest 0x200.
+ * Possibly we would also round down full_size to the nearest 0x200 but
+ * full_size/0x200 = (1 + ceil(W / w) * ceil(H / h)) is an integer so there's
+ * nothing to do.
*/
/* Hierarchical tiling spans from 16x16 to 4096x4096 tiles */