src/panfrost/encoder/pan_tiler.c

   1 /*
   2  * Copyright (C) 2019 Collabora, Ltd.
   3  *
   4  * Permission is hereby granted, free of charge, to any person obtaining a
   5  * copy of this software and associated documentation files (the "Software"),
   6  * to deal in the Software without restriction, including without limitation
   7  * the rights to use, copy, modify, merge, publish, distribute, sublicense,
   8  * and/or sell copies of the Software, and to permit persons to whom the
   9  * Software is furnished to do so, subject to the following conditions:
  10  *
  11  * The above copyright notice and this permission notice (including the next
  12  * paragraph) shall be included in all copies or substantial portions of the
  13  * Software.
  14  *
  15  * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
  16  * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
  17  * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
  18  * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
  19  * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
  20  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  21  * SOFTWARE.
  22  *
  23  * Authors:
  24  *   Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
  25  */
  26
  27 #include "util/u_math.h"
  28 #include "util/macros.h"
  29 #include "pan_encoder.h"
  30
  31 /* Mali GPUs are tiled-mode renderers, rather than immediate-mode.
  32  * Conceptually, the screen is divided into 16x16 tiles. Vertex shaders run.
  33  * Then, a fixed-function hardware block (the tiler) consumes the gl_Position
  34  * results. For each triangle specified, it marks each containing tile as
  35  * containing that triangle. This set of "triangles per tile" form the "polygon
  36  * list". Finally, the rasterization unit consumes the polygon list to invoke
  37  * the fragment shader.
  38  *
  39  * In practice, it's a bit more complicated than this. 16x16 is the logical
  40  * tile size, but Midgard features "hierarchical tiling", where power-of-two
  41  * multiples of the base tile size can be used: hierarchy level 0 (16x16),
  42  * level 1 (32x32), level 2 (64x64), per public information about Midgard's
  43  * tiling. In fact, tiling goes up to 4096x4096 (!), although in practice
  44  * 128x128 is the largest usually used (though higher modes are enabled).  The
  45  * idea behind hierarchical tiling is to use low tiling levels for small
  46  * triangles and high levels for large triangles, to minimize memory bandwidth
  47  * and repeated fragment shader invocations (the former issue inherent to
  48  * immediate-mode rendering and the latter common in traditional tilers).
  49  *
  50  * The tiler itself works by reading varyings in and writing a polygon list
  51  * out. Unfortunately (for us), both of these buffers are managed in main
  52  * memory; although they ideally will be cached, it is the drivers'
  53  * responsibility to allocate these buffers. Varying buffer allocation is
  54  * handled elsewhere, as it is not tiler specific; the real issue is allocating
  55  * the polygon list.
  56  *
  57  * This is hard, because from the driver's perspective, we have no information
  58  * about what geometry will actually look like on screen; that information is
  59  * only gained from running the vertex shader. (Theoretically, we could run the
  60  * vertex shaders in software as a prepass, or in hardware with transform
  61  * feedback as a prepass, but either idea is ludicrous on so many levels).
  62  *
  63  * Instead, Mali uses a bit of a hybrid approach, splitting the polygon list
  64  * into three distinct pieces. First, the driver statically determines which
  65  * tile hierarchy levels to use (more on that later). At this point, we know the
  66  * framebuffer dimensions and all the possible tilings of the framebuffer, so
  67  * we know exactly how many tiles exist across all hierarchy levels. The first
  68  * piece of the polygon list is the header, which is exactly 8 bytes per tile,
  69  * plus padding and a small 64-byte prologue. (If that doesn't remind you of
  70  * AFBC, it should. See pan_afbc.c for some fun parallels). The next part is
  71  * the polygon list body, which seems to contain 512 bytes per tile, again
  72  * across every level of the hierarchy. These two parts form the polygon list
  73  * buffer. This buffer has a statically determinable size, approximately equal
  74  * to the # of tiles across all hierarchy levels * (8 bytes + 512 bytes), plus
  75  * alignment / minimum restrictions / etc.
  76  *
  77  * The third piece is the easy one (for us): the tiler heap. In essence, the
  78  * tiler heap is a gigantic slab that's as big as could possibly be necessary
  79  * in the worst case imaginable. Just... a gigantic allocation that we give a
  80  * start and end pointer to. What's the catch? The tiler heap is lazily
  81  * allocated; that is, a huge amount of memory is _reserved_, but only a tiny
  82  * bit is actually allocated upfront. The GPU just keeps using the
  83  * unallocated-but-reserved portions as it goes along, generating page faults
  84  * if it goes beyond the allocation, and then the kernel is instructed to
  85  * expand the allocation on page fault (known in the vendor kernel as growable
  86  * memory). This is quite a bit of bookkeeping of its own, but that task is
  87  * pushed to kernel space and we can mostly ignore it here, just remembering to
  88  * set the GROWABLE flag so the kernel actually uses this path rather than
  89  * allocating a gigantic amount up front and burning a hole in RAM.
  90  *
  91  * As far as determining which hierarchy levels to use, the simple answer is
  92  * that right now, we don't. In the tiler configuration fields (consistent from
  93  * the earliest Midgard's SFBD through the latest Bifrost traces we have),
  94  * there is a hierarchy_mask field, controlling which levels (tile sizes) are
  95  * enabled. Ideally, the hierarchical tiling dream -- mapping big polygons to
  96  * big tiles and small polygons to small tiles -- would be realized here as
  97  * well. As long as there are polygons at all needing tiling, we always have to
  98  * have big tiles available, in case there are big polygons. But we don't
  99  * necessarily need small tiles available. Ideally, when there are small
 100  * polygons, small tiles are enabled (to avoid waste from putting small
 101  * triangles in the big tiles); when there are not, small tiles are disabled to
 102  * avoid enabling more levels than necessary, which potentially costs in memory
 103  * bandwidth / power / tiler performance.
 104  *
 105  * Of course, the driver has to figure this out statically. When tile
 106  * hiearchies are actually established, this occurs by the tiler in
 107  * fixed-function hardware, after the vertex shaders have run and there is
 108  * sufficient information to figure out the size of triangles. The driver has
 109  * no such luxury, again barring insane hacks like additionally running the
 110  * vertex shaders in software or in hardware via transform feedback. Thus, for
 111  * the driver, we need a heuristic approach.
 112  *
 113  * There are lots of heuristics to guess triangle size statically you could
 114  * imagine, but one approach shines as particularly simple-stupid: assume all
 115  * on-screen triangles are equal size and spread equidistantly throughout the
 116  * screen. Let's be clear, this is NOT A VALID ASSUMPTION. But if we roll with
 117  * it, then we see:
 118  *
 119  *      Triangle Area   = (Screen Area / # of triangles)
 120  *                      = (Width * Height) / (# of triangles)
 121  *
 122  * Or if you prefer, we can also make a third CRAZY assumption that we only draw
 123  * right triangles with edges parallel/perpendicular to the sides of the screen
 124  * with no overdraw, forming a triangle grid across the screen:
 125  *
 126  * |--w--|
 127  *  _____   |
 128  * | /| /|  |
 129  * |/_|/_|  h
 130  * | /| /|  |
 131  * |/_|/_|  |
 132  *
 133  * Then you can use some middle school geometry and algebra to work out the
 134  * triangle dimensions. I started working on this, but realised I didn't need
 135  * to to make my point, but couldn't bare to erase that ASCII art. Anyway.
 136  *
 137  * POINT IS, by considering the ratio of screen area and triangle count, we can
 138  * estimate the triangle size. For a small size, use small bins; for a large
 139  * size, use large bins. Intuitively, this metric makes sense: when there are
 140  * few triangles on a large screen, you're probably compositing a UI and
 141  * therefore the triangles are large; when there are a lot of triangles on a
 142  * small screen, you're probably rendering a 3D mesh and therefore the
 143  * triangles are tiny. (Or better said -- there will be tiny triangles, even if
 144  * there are also large triangles. There have to be unless you expect crazy
 145  * overdraw. Generally, it's better to allow more small bin sizes than
 146  * necessary than not allow enough.)
 147  *
 148  * From this heuristic (or whatever), we determine the minimum allowable tile
 149  * size, and we use that to decide the hierarchy masking, selecting from the
 150  * minimum "ideal" tile size to the maximum tile size (2048x2048 in practice).
 151  *
 152  * Once we have that mask and the framebuffer dimensions, we can compute the
 153  * size of the statically-sized polygon list structures, allocate them, and go!
 154  *
 155  */
 156
 157 /* Hierarchical tiling spans from 16x16 to 4096x4096 tiles */
 158
 159 #define MIN_TILE_SIZE 16
 160 #define MAX_TILE_SIZE 4096
 161
 162 /* Constants as shifts for easier power-of-two iteration */
 163
 164 #define MIN_TILE_SHIFT util_logbase2(MIN_TILE_SIZE)
 165 #define MAX_TILE_SHIFT util_logbase2(MAX_TILE_SIZE)
 166
 167 /* The hierarchy has a 64-byte prologue */
 168 #define PROLOGUE_SIZE 0x40
 169
 170 /* For each tile (across all hierarchy levels), there is 8 bytes of header */
 171 #define HEADER_BYTES_PER_TILE 0x8
 172
 173 /* Likewise, each tile per level has 512 bytes of body */
 174 #define FULL_BYTES_PER_TILE 0x200
 175
 176 /* Absent any geometry, the minimum size of the header */
 177 #define MINIMUM_HEADER_SIZE 0x200
 178
 179 /* Mask of valid hierarchy levels: one bit for each level from min...max
 180  * inclusive */
 181 #define HIERARCHY_MASK (((MAX_TILE_SIZE / MIN_TILE_SIZE) << 1) - 1)
 182
 183 /* If the width-x-height framebuffer is divided into tile_size-x-tile_size
 184  * tiles, how many tiles are there? Rounding up in each direction. For the
 185  * special case of tile_size=16, this aligns with the usual Midgard count.
 186  * tile_size must be a power-of-two. Not really repeat code from AFBC/checksum,
 187  * because those care about the stride (not just the overall count) and only at
 188  * a a fixed-tile size (not any of a number of power-of-twos) */
 189
 190 static unsigned
 191 pan_tile_count(unsigned width, unsigned height, unsigned tile_size)
 192 {
 193         unsigned aligned_width = ALIGN_POT(width, tile_size);
 194         unsigned aligned_height = ALIGN_POT(height, tile_size);
 195
 196         unsigned tile_count_x = aligned_width / tile_size;
 197         unsigned tile_count_y = aligned_height / tile_size;
 198
 199         return tile_count_x * tile_count_y;
 200 }
 201
 202 /* For `masked_count` of the smallest tile sizes masked out, computes how the
 203  * size of the polygon list header. We iterate the tile sizes (16x16 through
 204  * 2048x2048, if nothing is masked; (16*2^masked_count)x(16*2^masked_count)
 205  * through 2048x2048 more generally. For each tile size, we figure out how many
 206  * tiles there are at this hierarchy level and therefore many bytes this level
 207  * is, leaving us with a byte count for each level. We then just sum up the
 208  * byte counts across the levels to find a byte count for all levels. */
 209
 210 static unsigned
 211 panfrost_raw_segment_size(
 212                 unsigned width,
 213                 unsigned height,
 214                 unsigned masked_count,
 215                 unsigned end_level,
 216                 unsigned bytes_per_tile)
 217 {
 218         unsigned size = PROLOGUE_SIZE;
 219
 220         /* Normally we start at 16x16 tiles (MIN_TILE_SHIFT), but we add more
 221          * if anything is masked off */
 222
 223         unsigned start_level = MIN_TILE_SHIFT + masked_count;
 224
 225         /* Iterate hierarchy levels / tile sizes */
 226
 227         for (unsigned i = start_level; i <= end_level; ++i) {
 228                 /* Shift from a level to a tile size */
 229                 unsigned tile_size = (1 << i);
 230
 231                 unsigned tile_count = pan_tile_count(width, height, tile_size);
 232                 unsigned level_count = bytes_per_tile * tile_count;
 233
 234                 size += level_count;
 235         }
 236
 237         /* This size will be used as an offset, so ensure it's aligned */
 238         return ALIGN_POT(size, 512);
 239 }
 240
 241 /* Given a hierarchy mask and a framebuffer size, compute the size of one of
 242  * the segments (header or body) */
 243
 244 static unsigned
 245 panfrost_segment_size(
 246                 unsigned width, unsigned height,
 247                 unsigned mask, unsigned bytes_per_tile)
 248 {
 249         /* The tiler-disabled case should have been handled by the caller */
 250         assert(mask);
 251
 252         /* Some levels are enabled. Ensure that only smaller levels are
 253          * disabled and there are no gaps. Theoretically the hardware is more
 254          * flexible, but there's no known reason to use other configurations
 255          * and this keeps the code simple. Since we know the 0x80 or 0x100 bit
 256          * is set, ctz(mask) will return the number of masked off levels. */
 257
 258         unsigned masked_count = __builtin_ctz(mask);
 259
 260         assert(mask & (0x80 | 0x100));
 261         assert(((mask >> masked_count) & ((mask >> masked_count) + 1)) == 0);
 262
 263         /* Figure out the top level */
 264         unsigned unused_count = __builtin_clz(mask);
 265         unsigned top_bit = ((8 * sizeof(mask)) - 1) - unused_count;
 266
 267         /* We don't have bits for nonexistant levels below 16x16 */
 268         unsigned top_level = top_bit + 4;
 269
 270         /* Everything looks good. Use the number of trailing zeroes we found to
 271          * figure out how many smaller levels are disabled to compute the
 272          * actual header size */
 273
 274         return panfrost_raw_segment_size(width, height,
 275                         masked_count, top_level, bytes_per_tile);
 276 }
 277
 278
 279 /* Given a hierarchy mask and a framebuffer size, compute the header size */
 280
 281 unsigned
 282 panfrost_tiler_header_size(unsigned width, unsigned height, unsigned mask)
 283 {
 284         mask &= HIERARCHY_MASK;
 285
 286         /* If no hierarchy levels are enabled, that means there is no geometry
 287          * for the tiler to process, so use a minimum size. Used for clears */
 288
 289         if (mask == 0x00)
 290                 return MINIMUM_HEADER_SIZE;
 291
 292         return panfrost_segment_size(width, height, mask, HEADER_BYTES_PER_TILE);
 293 }
 294
 295 /* The combined header/body is sized similarly (but it is significantly
 296  * larger), except that it can be empty when the tiler disabled, rather than
 297  * getting clamped to a minimum size.
 298  */
 299
 300 unsigned
 301 panfrost_tiler_full_size(unsigned width, unsigned height, unsigned mask)
 302 {
 303         mask &= HIERARCHY_MASK;
 304
 305         if (mask == 0x00)
 306                 return MINIMUM_HEADER_SIZE;
 307
 308         return panfrost_segment_size(width, height, mask, FULL_BYTES_PER_TILE);
 309 }
 310
 311 /* In the future, a heuristic to choose a tiler hierarchy mask would go here.
 312  * At the moment, we just default to 0xFF, which enables all possible hierarchy
 313  * levels. Overall this yields good performance but presumably incurs a cost in
 314  * memory bandwidth / power consumption / etc, at least on smaller scenes that
 315  * don't really need all the smaller levels enabled */
 316
 317 unsigned
 318 panfrost_choose_hierarchy_mask(
 319         unsigned width, unsigned height,
 320         unsigned vertex_count)
 321 {
 322         /* If there is no geometry, we don't bother enabling anything */
 323
 324         if (!vertex_count)
 325                 return 0x00;
 326
 327         /* Otherwise, default everything on. TODO: Proper tests */
 328
 329         return 0xFF;
 330 }