Vulkan-Docs/chapters/fragmentdensitymapops.txt
Jon Leech 194a7f4d0d Change log for September 8, 2019 Vulkan 1.1.122 spec update:
* Update release number to 122.

Internal Issues:

  * Add style guide language on not using standalone `+` signs (internal
    issue 736); not using leading whitespace for markup (internal issue
    747); and on keeping descriptions of a single API in a contiguous block
    of markup (internal issue 949), and apply them to the specification.
  * Add a glossary definition of "`constant integral expression`", pointing
    to the SPIR-V "`constant instruction`" definition (internal issue 1225).
  * Many minor edits to improve writing style consistency and capture
    additional style guidelines (internal issue 1553).
  * Clarify that <<fragops-depth-write, depth writes are not performed>> if
    there is no depth framebuffer attachment (internal issue 1771).
  * Allow implementations to use rectangular line style of interpolation for
    <<primsrast-lines-bresenham, wide Bresenham lines>>, though replicating
    attributes is still preferred. Clarify that code:FragCoord is not
    replicated (internal issue 1772).
  * Resolve a contradiction in valid usage statements for
    slink:VkImageCreateInfo and slink:VkImageStencilUsageCreateInfoEXT
    (internal issue 1773).
  * Add style guide discussion of markup for indented equations, and use
    markup workaround for asciidoctor 2 compatibility (internal issue 1793).
  * Deprecate the `<<VK_EXT_validation_flags>>` extension in `vk.xml` and
    the extension appendix (internal issue 1801).
  * Add a new checker script `scripts/xml_consistency.py`. This is not
    currently run as part of internal CI (internal merge request 3285).
  * Correct "`an`" -> "`a`" prepositions where needed (internal merge
    request 3334).
  * Clarify that the <<features-uniformBufferStandardLayout,
    pname:uniformBufferStandardLayout>> feature is only required when the
    extension defining it is supported (internal merge request 3341).
  * Bring scripts into closer sync with OpenXR, mainly through conversion of
    comments to docstrings where appropriate, and add gen-scripts-docs.sh
    (internal merge request 3324).
  * Correct pname:maxDrawMeshTasksCount to 2^16^-1 in the <<limits-required,
    Required Limits>> table (internal merge requests 3361).

New Extensions

  * `<<VK_IMG_format_pvrtc>>` (public issue 512).
2019-09-08 20:41:02 -07:00

123 lines
4.8 KiB
Plaintext

// Copyright (c) 2018-2019 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
[[fragmentdensitymapops]]
= Fragment Density Map Operations
== Fragment Density Map Operations Overview
When a fragment is generated in a render pass that has a fragment density
map attachment, its area is determined by the properties of the local
framebuffer region that the fragment occupies.
The framebuffer is divided into a uniform grid of these local regions, and
their fragment area property is derived from the density map with the
following operations:
* <<fragmentdensitymap-fetch-density-value,Fetch density value>>
** <<fragmentdensitymap-component-swizzle,Component swizzle>>
** <<fragmentdensitymap-component-mapping,Component mapping>>
* <<fragmentdensitymap-conversion-to-fragment-area,Fragment area
conversion>>
** <<fragmentdensitymap-fragment-area-filter,Fragment area filter>>
** <<fragmentdensitymap-fragment-area-clamp,Fragment area clamp>>
[[fragmentdensitymap-fetch-density-value]]
== Fetch Density Value
Each local framebuffer region at center coordinate [eq]#(x,y)# fetches a
texel from the fragment density map at integer coordinates:
{empty}:: latexmath:[i =
\lfloor{\frac{x}{fragmentDensityTexelSize_{width}}}\rfloor]
{empty}:: latexmath:[j =
\lfloor{\frac{y}{fragmentDensityTexelSize_{height}}}\rfloor]
Where the size of each region in the framebuffer is:
{empty}:: latexmath:[fragmentDensityTexelSize'_{width} =
{2^{\lceil{\log_2(\frac{framebuffer_{width}}{fragmentDensityMap_{width}})}\rceil}}]
{empty}:: latexmath:[fragmentDensityTexelSize'_{height} =
{2^{\lceil{\log_2(\frac{framebuffer_{height}}{fragmentDensityMap_{height}})}\rceil}}]
This region is subject to the limits in
sname:VkPhysicalDeviceFragmentDensityMapPropertiesEXT and therefore the
final region size is clamped:
{empty}:: latexmath:[fragmentDensityTexelSize_{width} =
\mathbin{clamp}(fragmentDensityTexelSize'_{width},minFragmentDensityTexelSize_{width},maxFragmentDensityTexelSize_{width})]
{empty}:: latexmath:[fragmentDensityTexelSize_{height} =
\mathbin{clamp}(fragmentDensityTexelSize'_{height},minFragmentDensityTexelSize_{height},maxFragmentDensityTexelSize_{height})]
When multiview is enabled for the render pass and the fragment density map
attachment view was created with pname:layerCount greater than `1`, the
density map layer that the texel is fetched from is:
{empty}:: latexmath:[layer = baseArrayLayer + ViewIndex]
Otherwise:
{empty}:: latexmath:[layer = baseArrayLayer]
The texel fetched from the density map at [eq]#(i,j,layer)# is next
converted to density with the following operations.
[[fragmentdensitymap-component-swizzle]]
=== Component Swizzle
The pname:components member of slink:VkImageViewCreateInfo is applied to the
fetched texel as defined in <<textures-component-swizzle,Image component
swizzle>>.
[[fragmentdensitymap-component-mapping]]
=== Component Mapping
The swizzled texel's components are mapped to a density value:
{empty}:: latexmath:[densityValue_{xy} = (C'_{r},C'_{g})]
[[fragmentdensitymap-conversion-to-fragment-area]]
== Fragment Area Conversion
Fragment area for the framebuffer region is undefined if the density fetched
is not a normalized floating-point value greater than `0.0`.
Otherwise, the fetched fragment area for that region is derived as:
{empty}:: latexmath:[fragmentArea_{wh} = \frac{1.0}{densityValue_{xy}}]
[[fragmentdensitymap-fragment-area-filter]]
=== Fragment Area Filter
Optionally, the implementation may: fetch additional density map texels in
an implementation defined window around [eq]#(i,j)#.
The texels follow the standard conversion steps up to and including
<<fragmentdensitymap-conversion-to-fragment-area,fragment area conversion>>.
A single fetched fragment area for the framebuffer region is chosen by the
implementation and must: have an area between the _min_ and _max_ areas of
the fetched set.
[[fragmentdensitymap-fragment-area-clamp]]
=== Fragment Area Clamp
The implementation may: clamp the fetched fragment area to one that it
supports.
The clamped fragment area must: have a size less than or equal to the
original fetched value.
Implementations may: vary the supported set of fragment areas per
framebuffer region.
Fragment area [eq]#(1,1)# must: always be in the supported set.
[NOTE]
.Note
====
For example, if the fetched fragment area is [eq]#(1,4)# but the
implementation only supports areas of [eq]#{(1,1),(2,2)}#, it could choose
to clamp the area to [eq]#(2,2)# since it has the same size as [eq]#(1,4)#.
While this would produce fragments that have lower quality strictly in the
x-axis, the overall density is maintained.
====
The clamped fragment area is assigned to the corresponding framebuffer
region.