OpenHarmony/third_party_mesa3d
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs/isl: Consistently use 3-space tabs

Browse Source 
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11529>
This commit is contained in:
Jason Ekstrand
2021-06-22 11:05:11 -05:00
committed by Marge Bot
parent 105a51b166
commit 806498eee8
3 changed files with 52 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
docs/isl/ccs.rst
View File

@@ -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 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): 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 The Color Control Surface (CCS) contains the compression status of the
cache-line pairs. The compression state of the cache-line pair is 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 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. on the main surface of 16x16 sets of 128 byte Y-tiled cache-line-pairs.
CCS is always Y tiled. CCS is always Y tiled.
While this is technically for color compression and not fast-clears, it 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 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): Broadwell PRM Vol 7, "MCS Buffer for Render Target(s)" (p. 676):
Mip-mapped and arrayed surfaces are supported with MCS buffer layout with Mip-mapped and arrayed surfaces are supported with MCS buffer layout with
these alignments in the RT space: Horizontal Alignment = 256 and Vertical these alignments in the RT space: Horizontal Alignment = 256 and Vertical
Alignment = 128. Alignment = 128.
Broadwell PRM Vol 2d, "RENDER_SURFACE_STATE" (p. 279): Broadwell PRM Vol 2d, "RENDER_SURFACE_STATE" (p. 279):
For non-multisampled render target's auxiliary surface, MCS, QPitch must be For non-multisampled render target's auxiliary surface, MCS, QPitch must be
computed with Horizontal Alignment = 256 and Surface Vertical Alignment = computed with Horizontal Alignment = 256 and Surface Vertical Alignment =
128. These alignments are only for MCS buffer and not for associated render 128. These alignments are only for MCS buffer and not for associated render
target. target.
Sky Lake PRM Vol 7, "MCS Buffer for Render Target(s)" (p. 632): 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 Mip-mapped and arrayed surfaces are supported with MCS buffer layout with
these alignments in the RT space: Horizontal Alignment = 128 and Vertical these alignments in the RT space: Horizontal Alignment = 128 and Vertical
Alignment = 64. Alignment = 64.
Sky Lake PRM Vol. 2d, "RENDER_SURFACE_STATE" (p. 435): Sky Lake PRM Vol. 2d, "RENDER_SURFACE_STATE" (p. 435):
For non-multisampled render target's CCS auxiliary surface, QPitch must be For non-multisampled render target's CCS auxiliary surface, QPitch must be
computed with Horizontal Alignment = 128 and Surface Vertical Alignment computed with Horizontal Alignment = 128 and Surface Vertical Alignment
= 256. These alignments are only for CCS buffer and not for associated = 256. These alignments are only for CCS buffer and not for associated
render target. render target.
Empirical evidence seems to confirm this. On Sky Lake, the vertical alignment Empirical evidence seems to confirm this. On Sky Lake, the vertical alignment
is always one cache line. The horizontal alignment, however, varies by main is always one cache line. The horizontal alignment, however, varies by main

40
docs/isl/hiz.rst
View File

@@ -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. From the Sandy Bridge PRM Vol. 2, Pt. 1, 7.5.3 "Hierarchical Depth Buffer" (p.
312): 312):
The hierarchical depth buffer does not support the LOD field, it is assumed 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 by hardware to be zero. A separate hierarachical depth buffer is required
for each LOD used, and the corresponding buffer’s state delivered to 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. hardware each time a new depth buffer state with modified LOD is delivered.
The ``3DSTATE_STENCIL_BUFFER`` packet for separate stencil (required for HiZ) The ``3DSTATE_STENCIL_BUFFER`` packet for separate stencil (required for HiZ)
on sandy bridge also lacks an LOD field. Empirically, the hardware doesn't 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 .. code-block:: c
struct blorp_address hiz_address = params->depth.aux_addr; struct blorp_address hiz_address = params->depth.aux_addr;
#if GFX_VER == 6 #if GFX_VER == 6
/* Sandy bridge hardware does not technically support mipmapped HiZ. /* Sandy bridge hardware does not technically support mipmapped HiZ.
* However, we have a special layout that allows us to make it work * However, we have a special layout that allows us to make it work
* anyway by manually offsetting to the specified miplevel. * anyway by manually offsetting to the specified miplevel.
*/ */
assert(info.hiz_surf->dim_layout == ISL_DIM_LAYOUT_GFX6_STENCIL_HIZ); assert(info.hiz_surf->dim_layout == ISL_DIM_LAYOUT_GFX6_STENCIL_HIZ);
uint32_t offset_B; uint32_t offset_B;
isl_surf_get_image_offset_B_tile_sa(info.hiz_surf, isl_surf_get_image_offset_B_tile_sa(info.hiz_surf,
info.view->base_level, 0, 0, info.view->base_level, 0, 0,
&offset_B, NULL, NULL); &offset_B, NULL, NULL);
hiz_address.offset += offset_B; hiz_address.offset += offset_B;
#endif #endif
info.hiz_address = info.hiz_address =
blorp_emit_reloc(batch, dw + isl_dev->ds.hiz_offset / 4, blorp_emit_reloc(batch, dw + isl_dev->ds.hiz_offset / 4,
hiz_address, 0); hiz_address, 0);

26
docs/isl/tiling.rst
View File

@@ -83,11 +83,11 @@ image in bytes given a width and height in elements is as follows:
.. code-block:: c .. code-block:: c
uint32_t width_tl = DIV_ROUND_UP(width_el * (format_bpb / tile_info.format_bpb), uint32_t width_tl = DIV_ROUND_UP(width_el * (format_bpb / tile_info.format_bpb),
tile_info.logical_extent_el.w); tile_info.logical_extent_el.w);
uint32_t height_tl = DIV_ROUND_UP(height_el, tile_info.logical_extent_el.h); 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 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 size = height_tl * tile_info.phys_extent_el.h * row_pitch;
It is very important to note that there is no direct conversion between It is very important to note that there is no direct conversion between
:cpp:member:`isl_tile_info::logical_extent_el` and :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, easiest case study for this is W-tiling. From the Sky Lake PRM Vol. 2d,
"RENDER_SURFACE_STATE" (p. 427): "RENDER_SURFACE_STATE" (p. 427):
If the surface is a stencil buffer (and thus has Tile Mode set to 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 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. 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 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 mean that "the stencil buffer is stored with two rows interleaved"? The
@@ -156,7 +156,7 @@ tiled address:
.. code-block:: c .. code-block:: c
addr[6] ^= addr[9] ^ addr[10]; addr[6] ^= addr[9] ^ addr[10];
Y-tiling Y-tiling
-------- --------
@@ -199,7 +199,7 @@ address:
.. code-block:: c .. code-block:: c
addr[6] ^= addr[9]; addr[6] ^= addr[9];
W-tiling 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 requirement that W-tiled buffers have their pitch multiplied by 2. From the
Sky Lake PRM Vol. 2d, "RENDER_SURFACE_STATE" (p. 427): Sky Lake PRM Vol. 2d, "RENDER_SURFACE_STATE" (p. 427):
If the surface is a stencil buffer (and thus has Tile Mode set to 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 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. 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 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 interleaved". More accurately, a W-tiled buffer can be viewed as a Y-tiled