Mesa (main): docs/isl: Consistently use 3-space tabs
GitLab Mirror
gitlab-mirror at kemper.freedesktop.org
Tue Jun 22 17:41:05 UTC 2021
Module: Mesa
Branch: main
Commit: 806498eee8f0d39897c1727b82ab08cbc75f1ee5
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=806498eee8f0d39897c1727b82ab08cbc75f1ee5
Author: Jason Ekstrand <jason at jlekstrand.net>
Date: Tue Jun 22 11:05:11 2021 -0500
docs/isl: Consistently use 3-space tabs
Reviewed-by: Connor Abbott <cwabbott0 at gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11529>
---
docs/isl/ccs.rst | 38 +++++++++++++++++++-------------------
docs/isl/hiz.rst | 40 ++++++++++++++++++++--------------------
docs/isl/tiling.rst | 26 +++++++++++++-------------
3 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/docs/isl/ccs.rst b/docs/isl/ccs.rst
index 37797705cc9..974568e70b7 100644
--- a/docs/isl/ccs.rst
+++ b/docs/isl/ccs.rst
@@ -38,11 +38,11 @@ about the contents of the CCS is gleaned from reverse-engineering of the
hardware. The best bit of documentation we have ever had comes from the
display section of the Sky Lake PRM Vol 12 section on planes (p. 159):
- The Color Control Surface (CCS) contains the compression status of the
- cache-line pairs. The compression state of the cache-line pair is
- specified by 2 bits in the CCS. Each CCS cache-line represents an area
- on the main surface of 16x16 sets of 128 byte Y-tiled cache-line-pairs.
- CCS is always Y tiled.
+ The Color Control Surface (CCS) contains the compression status of the
+ cache-line pairs. The compression state of the cache-line pair is
+ specified by 2 bits in the CCS. Each CCS cache-line represents an area
+ on the main surface of 16x16 sets of 128 byte Y-tiled cache-line-pairs.
+ CCS is always Y tiled.
While this is technically for color compression and not fast-clears, it
provides a good bit of insight into how color compression and fast-clears
@@ -96,29 +96,29 @@ this as follows:
Broadwell PRM Vol 7, "MCS Buffer for Render Target(s)" (p. 676):
- Mip-mapped and arrayed surfaces are supported with MCS buffer layout with
- these alignments in the RT space: Horizontal Alignment = 256 and Vertical
- Alignment = 128.
+ Mip-mapped and arrayed surfaces are supported with MCS buffer layout with
+ these alignments in the RT space: Horizontal Alignment = 256 and Vertical
+ Alignment = 128.
Broadwell PRM Vol 2d, "RENDER_SURFACE_STATE" (p. 279):
- For non-multisampled render target's auxiliary surface, MCS, QPitch must be
- computed with Horizontal Alignment = 256 and Surface Vertical Alignment =
- 128. These alignments are only for MCS buffer and not for associated render
- target.
+ For non-multisampled render target's auxiliary surface, MCS, QPitch must be
+ computed with Horizontal Alignment = 256 and Surface Vertical Alignment =
+ 128. These alignments are only for MCS buffer and not for associated render
+ target.
Sky Lake PRM Vol 7, "MCS Buffer for Render Target(s)" (p. 632):
- Mip-mapped and arrayed surfaces are supported with MCS buffer layout with
- these alignments in the RT space: Horizontal Alignment = 128 and Vertical
- Alignment = 64.
+ Mip-mapped and arrayed surfaces are supported with MCS buffer layout with
+ these alignments in the RT space: Horizontal Alignment = 128 and Vertical
+ Alignment = 64.
Sky Lake PRM Vol. 2d, "RENDER_SURFACE_STATE" (p. 435):
- For non-multisampled render target's CCS auxiliary surface, QPitch must be
- computed with Horizontal Alignment = 128 and Surface Vertical Alignment
- = 256. These alignments are only for CCS buffer and not for associated
- render target.
+ For non-multisampled render target's CCS auxiliary surface, QPitch must be
+ computed with Horizontal Alignment = 128 and Surface Vertical Alignment
+ = 256. These alignments are only for CCS buffer and not for associated
+ render target.
Empirical evidence seems to confirm this. On Sky Lake, the vertical alignment
is always one cache line. The horizontal alignment, however, varies by main
diff --git a/docs/isl/hiz.rst b/docs/isl/hiz.rst
index 748eec249c6..0d3b34aaaea 100644
--- a/docs/isl/hiz.rst
+++ b/docs/isl/hiz.rst
@@ -10,10 +10,10 @@ Properly enabling HiZ on Sandy Bridge requires certain special considerations.
From the Sandy Bridge PRM Vol. 2, Pt. 1, 7.5.3 "Hierarchical Depth Buffer" (p.
312):
- The hierarchical depth buffer does not support the LOD field, it is assumed
- by hardware to be zero. A separate hierarachical depth buffer is required
- for each LOD used, and the corresponding buffer’s state delivered to
- hardware each time a new depth buffer state with modified LOD is delivered.
+ The hierarchical depth buffer does not support the LOD field, it is assumed
+ by hardware to be zero. A separate hierarachical depth buffer is required
+ for each LOD used, and the corresponding buffer’s state delivered to
+ hardware each time a new depth buffer state with modified LOD is delivered.
The ``3DSTATE_STENCIL_BUFFER`` packet for separate stencil (required for HiZ)
on sandy bridge also lacks an LOD field. Empirically, the hardware doesn't
@@ -55,20 +55,20 @@ do this as an example:
.. code-block:: c
- struct blorp_address hiz_address = params->depth.aux_addr;
- #if GFX_VER == 6
- /* Sandy bridge hardware does not technically support mipmapped HiZ.
- * However, we have a special layout that allows us to make it work
- * anyway by manually offsetting to the specified miplevel.
- */
- assert(info.hiz_surf->dim_layout == ISL_DIM_LAYOUT_GFX6_STENCIL_HIZ);
- uint32_t offset_B;
- isl_surf_get_image_offset_B_tile_sa(info.hiz_surf,
- info.view->base_level, 0, 0,
- &offset_B, NULL, NULL);
- hiz_address.offset += offset_B;
- #endif
+ struct blorp_address hiz_address = params->depth.aux_addr;
+ #if GFX_VER == 6
+ /* Sandy bridge hardware does not technically support mipmapped HiZ.
+ * However, we have a special layout that allows us to make it work
+ * anyway by manually offsetting to the specified miplevel.
+ */
+ assert(info.hiz_surf->dim_layout == ISL_DIM_LAYOUT_GFX6_STENCIL_HIZ);
+ uint32_t offset_B;
+ isl_surf_get_image_offset_B_tile_sa(info.hiz_surf,
+ info.view->base_level, 0, 0,
+ &offset_B, NULL, NULL);
+ hiz_address.offset += offset_B;
+ #endif
- info.hiz_address =
- blorp_emit_reloc(batch, dw + isl_dev->ds.hiz_offset / 4,
- hiz_address, 0);
+ info.hiz_address =
+ blorp_emit_reloc(batch, dw + isl_dev->ds.hiz_offset / 4,
+ hiz_address, 0);
diff --git a/docs/isl/tiling.rst b/docs/isl/tiling.rst
index 462ce87754a..8571e62e8bd 100644
--- a/docs/isl/tiling.rst
+++ b/docs/isl/tiling.rst
@@ -83,11 +83,11 @@ image in bytes given a width and height in elements is as follows:
.. code-block:: c
- uint32_t width_tl = DIV_ROUND_UP(width_el * (format_bpb / tile_info.format_bpb),
- tile_info.logical_extent_el.w);
- uint32_t height_tl = DIV_ROUND_UP(height_el, tile_info.logical_extent_el.h);
- uint32_t row_pitch = width_tl * tile_info.phys_extent_el.w;
- uint32_t size = height_tl * tile_info.phys_extent_el.h * row_pitch;
+ uint32_t width_tl = DIV_ROUND_UP(width_el * (format_bpb / tile_info.format_bpb),
+ tile_info.logical_extent_el.w);
+ uint32_t height_tl = DIV_ROUND_UP(height_el, tile_info.logical_extent_el.h);
+ uint32_t row_pitch = width_tl * tile_info.phys_extent_el.w;
+ uint32_t size = height_tl * tile_info.phys_extent_el.h * row_pitch;
It is very important to note that there is no direct conversion between
:cpp:member:`isl_tile_info::logical_extent_el` and
@@ -100,9 +100,9 @@ heights that differ and so no such calculation will work in general. The
easiest case study for this is W-tiling. From the Sky Lake PRM Vol. 2d,
"RENDER_SURFACE_STATE" (p. 427):
- If the surface is a stencil buffer (and thus has Tile Mode set to
- TILEMODE_WMAJOR), the pitch must be set to 2x the value computed based on
- width, as the stencil buffer is stored with two rows interleaved.
+ If the surface is a stencil buffer (and thus has Tile Mode set to
+ TILEMODE_WMAJOR), the pitch must be set to 2x the value computed based on
+ width, as the stencil buffer is stored with two rows interleaved.
What does this mean? Why are we multiplying the pitch by two? What does it
mean that "the stencil buffer is stored with two rows interleaved"? The
@@ -156,7 +156,7 @@ tiled address:
.. code-block:: c
- addr[6] ^= addr[9] ^ addr[10];
+ addr[6] ^= addr[9] ^ addr[10];
Y-tiling
--------
@@ -199,7 +199,7 @@ address:
.. code-block:: c
- addr[6] ^= addr[9];
+ addr[6] ^= addr[9];
W-tiling
--------
@@ -228,9 +228,9 @@ as a sort of modified Y-tiling. One example of this is the somewhat odd
requirement that W-tiled buffers have their pitch multiplied by 2. From the
Sky Lake PRM Vol. 2d, "RENDER_SURFACE_STATE" (p. 427):
- If the surface is a stencil buffer (and thus has Tile Mode set to
- TILEMODE_WMAJOR), the pitch must be set to 2x the value computed based on
- width, as the stencil buffer is stored with two rows interleaved.
+ If the surface is a stencil buffer (and thus has Tile Mode set to
+ TILEMODE_WMAJOR), the pitch must be set to 2x the value computed based on
+ width, as the stencil buffer is stored with two rows interleaved.
The last phrase holds the key here: "the stencil buffer is stored with two rows
interleaved". More accurately, a W-tiled buffer can be viewed as a Y-tiled
More information about the mesa-commit
mailing list