The T tiling format is what V3D uses for textures, with no raster support at all until later revisions of the hardware (and always at a large 3D performance penalty). If we can't scan out V3D's format, then we often need to do a relayout at some stage of the pipeline, either right before texturing from the scanout buffer (common in X11 without a compositor) or between a tiled screen buffer right before scanout (an option I've considered in trying to resolve this inconsistency, but which means needing to use the dirty fb ioctl and having some update policy). T-format scanout lets us avoid either of those shadow copies, for a massive, obvious performance improvement to X11 window dragging without a compositor. Unfortunately, enabling a compositor to work around the discrepancy has turned out to be too costly in memory consumption for the Raspbian distribution. Because the HVS operates a scanline at a time, compositing from T does increase the memory bandwidth cost of scanout. On my 1920x1080@32bpp display on a RPi3, we go from about 15% of system memory bandwidth with linear to about 20% with tiled. However, for X11 this still ends up being a huge performance win in active usage. This patch doesn't yet handle src_x/src_y offsetting within the tiled buffer. However, we fail to do so for untiled buffers already.
Showing the changes to include/uapi (1 of 3 files). Show all
Unified · Split
| @@ -182,6 +182,7 @@ extern "C" { · 181 unmodified lines | |||
| 182 | #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04 | 182 | #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04 |
| 183 | #define DRM_FORMAT_MOD_VENDOR_QCOM 0x05 | 183 | #define DRM_FORMAT_MOD_VENDOR_QCOM 0x05 |
| 184 | #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06 | 184 | #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06 |
| 185 | #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07 | ||
| 185 | /* add more to the end as needed */ | 186 | /* add more to the end as needed */ |
| 186 | 187 | ||
| 187 | #define fourcc_mod_code(vendor, val) \ | 188 | #define fourcc_mod_code(vendor, val) \ |
| @@ -306,7 +307,6 @@ extern "C" { · 118 unmodified lines | |||
| 306 | */ | 307 | */ |
| 307 | #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4) | 308 | #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4) |
| 308 | 309 | ||
| 309 | |||
| 310 | /* NVIDIA Tegra frame buffer modifiers */ | 310 | /* NVIDIA Tegra frame buffer modifiers */ |
| 311 | 311 | ||
| 312 | /* | 312 | /* |
| @@ -351,6 +351,27 @@ extern "C" { · 38 unmodified lines | |||
| 351 | */ | 351 | */ |
| 352 | #define NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(v) fourcc_mod_tegra_code(2, v) | 352 | #define NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(v) fourcc_mod_tegra_code(2, v) |
| 353 | 353 | ||
| 354 | /* | ||
| 355 | * Broadcom VC4 "T" format | ||
| 356 | * | ||
| 357 | * This is the primary layout that the V3D GPU can texture from (it | ||
| 358 | * can't do linear). The T format has: | ||
| 359 | * | ||
| 360 | * - 64b utiles of pixels in a raster-order grid according to cpp. It's 4x4 | ||
| 361 | * pixels at 32 bit depth. | ||
| 362 | * | ||
| 363 | * - 1k subtiles made of a 4x4 raster-order grid of 64b utiles (so usually | ||
| 364 | * 16x16 pixels). | ||
| 365 | * | ||
| 366 | * - 4k tiles made of a 2x2 grid of 1k subtiles (so usually 32x32 pixels). On | ||
| 367 | * even 4k tile rows, they're arranged as (BL, TL, TR, BR), and on odd rows | ||
| 368 | * they're (TR, BR, BL, TL), where bottom left is start of memory. | ||
| 369 | * | ||
| 370 | * - an image made of 4k tiles in rows either left-to-right (even rows of 4k | ||
| 371 | * tiles) or right-to-left (odd rows of 4k tiles). | ||
| 372 | */ | ||
| 373 | #define DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED fourcc_mod_code(BROADCOM, 1) | ||
| 374 | |||
| 354 | #if defined(__cplusplus) | 375 | #if defined(__cplusplus) |
| 355 | } | 376 | } |
| 356 | #endif | 377 | #endif |