mesa/src/intel/isl
Jason Ekstrand c15b92ce11 intel/isl: Stop padding surfaces
The docs contain a bunch of commentary about the need to pad various
surfaces out to multiples of something or other.  However, all of those
requirements are about avoiding GTT errors due to missing pages when the
data port or sampler accesses slightly out-of-bounds.  However, because
the kernel already fills all the empty space in our GTT with the scratch
page, we never have to worry about faulting due to OOB reads.  There are
two caveats to this:

 1) There is some potential for issues with caches here if extra data
    ends up in a cache we don't expect due to OOB reads.  However,
    because we always trash the entire cache whenever we need to move
    anything between cache domains, this shouldn't be an issue.

 2) There is a potential issue if a surface gets placed at the very top
    of the GTT by the kernel.  In this case, the hardware could
    potentially end up trying to read past the top of the GTT.  If it
    nicely wraps around at the 48-bit (or 32-bit) boundary, then this
    shouldn't be an issue thanks to the scratch page.  If it doesn't,
    then we need to come up with something to handle it.

Up until some of the GL move to ISL, having the padding code in there
just caused us to harmlessly use a bit more memory in Vulkan.  However,
now that we're using ISL sizes to validate external dma-buf images,
these padding requirements are causing us to reject otherwise valid
images due to the size of the BO being too small.

Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Tapani Pälli <tapani.palli@intel.com>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: "17.2" <mesa-stable@lists.freedesktop.org>
2017-08-07 09:31:11 -07:00
..
tests intel/isl: Don't check array pitch for gen4 3D textures 2017-06-01 15:33:43 -07:00
.gitignore Move isl to src/intel 2016-02-18 10:34:47 -08:00
gen_format_layout.py intel/isl/format: Add an srgb_to_linear helper 2017-07-22 20:59:22 -07:00
isl.c intel/isl: Stop padding surfaces 2017-08-07 09:31:11 -07:00
isl.h intel/isl: Add a helper to get a subimage surface 2017-07-22 21:41:12 -07:00
isl_drm.c intel/isl: Add i915 to isl_tiling converter 2017-07-20 11:32:21 +03:00
isl_emit_depth_stencil.c intel/isl: Properly set SeparateStencilBufferEnable on gen5-6 2017-06-14 18:15:05 -07:00
isl_format.c intel/isl/gen7: Allow msaa with 128-bit formats 2017-07-22 00:14:16 +03:00
isl_format_layout.csv intel/isl: Add ASTC HDR to format lists and helpers 2017-05-22 11:13:53 -07:00
isl_gen4.c intel/isl: Add gen4_filter_tiling 2017-05-26 07:58:01 -07:00
isl_gen4.h intel/isl: Add gen4_filter_tiling 2017-05-26 07:58:01 -07:00
isl_gen6.c intel/isl/gen6: Fix combined depth stencil alignment 2017-05-16 17:04:26 -07:00
isl_gen6.h isl: use ifndef header guards 2016-10-14 11:53:32 +01:00
isl_gen7.c intel/isl/gen7: Don't allow multisampled surfaces with valign2 2017-07-22 00:14:16 +03:00
isl_gen7.h isl: use ifndef header guards 2016-10-14 11:53:32 +01:00
isl_gen8.c intel/isl: Refactor gen8_choose_image_alignment_el 2017-05-16 17:04:26 -07:00
isl_gen8.h isl: use ifndef header guards 2016-10-14 11:53:32 +01:00
isl_gen9.c isl: prefix non-static API with isl_ 2016-10-14 11:53:22 +01:00
isl_gen9.h isl: use ifndef header guards 2016-10-14 11:53:32 +01:00
isl_priv.h i965/cnl: Add gen10 specific function declarations 2017-06-09 16:02:58 -07:00
isl_storage_image.c intel/isl: Take 3D surfaces into account in image params 2017-07-18 21:35:44 +03:00
isl_surface_state.c intel/isl: Add some sanity checks for compressed surfaces 2017-07-22 21:41:12 -07:00
README Move isl to src/intel 2016-02-18 10:34:47 -08:00

Intel Surface Layout

Introduction
============
isl is a small library that calculates the layout of Intel GPU surfaces, queries
those layouts, and queries the properties of surface formats.


Independence from User APIs
===========================
isl's API is independent of any user-facing graphics API, such as OpenGL and
Vulkan. This independence allows isl to be used a shared component by multiple
Intel drivers.

Rather than mimic the user-facing APIs, the isl API attempts to reflect Intel
hardware: the actual memory layout of Intel GPU surfaces and how one programs
the GPU to use those surfaces. For example:

  - The tokens of `enum isl_format` (such as `ISL_FORMAT_R8G8B8A8_UNORM`)
    match those of the hardware enum `SURFACE_FORMAT` rather than the OpenGL
    or Vulkan format tokens.  And the values of `isl_format` and
    `SURFACE_FORMAT` are identical.

  - The OpenGL and Vulkan APIs contain depth and stencil formats. However the
    hardware enum `SURFACE_FORMAT` does not, and therefore neither does `enum
    isl_format`. Rather than define new pixel formats that have no hardware
    counterpart, isl records the intent to use a surface as a depth or stencil
    buffer with the usage flags `ISL_SURF_USAGE_DEPTH_BIT` and
    `ISL_SURF_USAGE_STENCIL_BIT`.

  - `struct isl_surf` distinguishes between the surface's logical dimension
    from the user API's perspective (`enum isl_surf_dim`, which may be 1D, 2D,
    or 3D) and the layout of those dimensions in memory (`enum isl_dim_layout`).


Surface Units
=============

Intro
-----
ISL takes care in its equations to correctly handle conversion among surface
units (such as pixels and compression blocks) and to carefully distinguish
between a surface's logical layout in the client API and its physical layout
in memory.

Symbol names often explicitly declare their unit with a suffix:

   - px: logical pixels
   - sa: physical surface samples
   - el: physical surface elements
   - sa_rows: rows of physical surface samples
   - el_rows: rows of physical surface elements

Logical units are independent of hardware generation and are closely related
to the user-facing API (OpenGL and Vulkan). Physical units are dependent on
hardware generation and reflect the surface's layout in memory.

Definitions
-----------
- Logical Pixels (px):

  The surface's layout from the perspective of the client API (OpenGL and
  Vulkan) is in units of logical pixels. Logical pixels are independent of the
  surface's layout in memory.

  A surface's width and height, in units of logical pixels, is not affected by
  the surface's sample count. For example, consider a VkImage created with
  VkImageCreateInfo{width=w0, height=h0, samples=s0}. The surface's width and
  height at level 0 is, in units of logical pixels, w0 and h0 regardless of
  the value of s0.

  For example, the logical array length of a 3D surface is always 1, even on
  Gen9 where the surface's memory layout is that of an array surface
  (ISL_DIM_LAYOUT_GEN4_2D).

- Physical Surface Samples (sa):

  For a multisampled surface, this unit has the obvious meaning.
  A singlesampled surface, from ISL's perspective, is simply a multisampled
  surface whose sample count is 1.

  For example, consider a 2D single-level non-array surface with samples=4,
  width_px=64, and height_px=64 (note that the suffix 'px' indicates logical
  pixels). If the surface's multisample layout is ISL_MSAA_LAYOUT_INTERLEAVED,
  then the extent of level 0 is, in units of physical surface samples,
  width_sa=128, height_sa=128, depth_sa=1, array_length_sa=1. If
  ISL_MSAA_LAYOUT_ARRAY, then width_sa=64, height_sa=64, depth_sa=1,
  array_length_sa=4.

- Physical Surface Elements (el):

  This unit allows ISL to treat compressed and uncompressed formats
  identically in many calculations.

  If the surface's pixel format is compressed, such as ETC2, then a surface
  element is equivalent to a compression block. If uncompressed, then
  a surface element is equivalent to a surface sample. As a corollary, for
  a given surface a surface element is at least as large as a surface sample.

Errata
------
ISL acquired the term 'surface element' from the Broadwell PRM [1], which
defines it as follows:

   An element is defined as a pixel in uncompresed surface formats, and as
   a compression block in compressed surface formats. For MSFMT_DEPTH_STENCIL
   type multisampled surfaces, an element is a sample.


References
==========
[1]: Broadwell PRM >> Volume 2d: Command Reference: Structures >>
     RENDER_SURFACE_STATE Surface Vertical Alignment (p325)