mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2024-12-14 12:44:04 +08:00
docs/isl: Consistently use 3-space tabs
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
Marge Bot
parent
105a51b166
commit
806498eee8
@ -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
|
||||
|
||||
@ -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);
|
||||
|
||||
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user