Vulkan-Docs/doc/specs/vulkan/appendices/VK_NV_framebuffer_mixed_samples.txt
Jon Leech 0cc6bba634 Change log for September 15, 2017 Vulkan 1.0.61 spec update:
* Bump API patch number and header version number to 61 for this update.

Github Issues:

  * Provide alternate length attributes (altlen=) in the XML schema, for
    those using length attributes to generate code instead of documentation
    (public issue 555).
  * Fix erroneous references to `latex:` being used for asciidoc math
    markup, rather than `latexmath:` (public pull request 556).
  * Add author ID to XML for Kazan software renderer (public pull request
    557).

Internal Issues:

  * Add the <<fundamentals-abi,Application Binary Interface>> section
    describing platform ABI requirements and recommendations, add examples
    of function and function pointer declarations to the
    <<boilerplate-platform-specific-calling-conventions, Platform-Specific
    Calling Conventions>> section, and remove related language that existed
    elsewhere in the specification (internal issue 64).
  * Describe where to document valid usage interactions of chained
    structures in the style guide, and fix one case now appearing in
    slink:VkBufferCreateInfo instead of the child
    slink:VkDedicatedAllocationBufferCreateInfoNV structure (internal issue
    715).
  * Add example to the style guide of describing enumerated types which are
    empty when the spec is built without relevant extensions enabled, and
    apply it to existing examples for
    elink:VkDescriptorSetLayoutCreateFlagBits and
    elink:VkSubpassDescriptionFlagBits (internal issue 864).
  * Add a note to the <<fundamentals-validusage-enums, Valid Usage for
    Enumerated Types>> section that the special values suffixed with
    etext:_BEGIN_RANGE, etext:_END_RANGE, etext:_RANGE_SIZE and
    etext:_MAX_ENUM are not part of the API and should: not be used by
    applications (internal issue 872).
  * Added note to flink:vkCmdUpdateBuffers explaining the performance
    penalty for copies done in this way, and why the upper copy limit is
    what it is (internal issue 952).
  * Update `VK_KHX_device_group` to split some functionality into the new
    `VK_KHR_bind_memory2` extension, and rename that functionality (internal
    issue 969).
  * Remove *Status* fields from extension appendices, since they are by
    definition published and complete by the time they reach the public
    github repository (internal issue 973).

Other Issues:

  * Update Data Format specification dependency to version 1.2 and change
    references to DF sections accordingly.
  * Update XML to make the pname:pAllocator parameter of
    flink:vkRegisterDeviceEventEXT and flink:vkRegisterDisplayEventEXT in
    the `VK_EXT_display_control` extension as optional.

New Extensions:

  * `VK_KHR_bind_memory2`
  * `VK_KHR_image_format_list`
  * `VK_KHR_maintenance2`
  * `VK_KHR_sampler_ycbcr_conversion`
2017-09-14 22:41:33 -07:00

77 lines
2.5 KiB
Plaintext

include::meta/VK_NV_framebuffer_mixed_samples.txt[]
*Last Modified Date*::
2017-06-04
*Contributors*::
- Jeff Bolz, NVIDIA
This extension allows multisample rendering with a raster and depth/stencil
sample count that is larger than the color sample count.
Rasterization and the results of the depth and stencil tests together
determine the portion of a pixel that is "covered".
It can be useful to evaluate coverage at a higher frequency than color
samples are stored.
This coverage is then "reduced" to a collection of covered color samples,
each having an opacity value corresponding to the fraction of the color
sample covered.
The opacity can optionally be blended into individual color samples.
Rendering with fewer color samples than depth/stencil samples greatly
reduces the amount of memory and bandwidth consumed by the color buffer.
However, converting the coverage values into opacity introduces artifacts
where triangles share edges and may: not be suitable for normal triangle
mesh rendering.
One expected use case for this functionality is Stencil-then-Cover path
rendering (similar to the OpenGL GL_NV_path_rendering extension).
The stencil step determines the coverage (in the stencil buffer) for an
entire path at the higher sample frequency, and then the cover step draws
the path into the lower frequency color buffer using the coverage
information to antialias path edges.
With this two-step process, internal edges are fully covered when
antialiasing is applied and there is no corruption on these edges.
The key features of this extension are:
* It allows render pass and framebuffer objects to be created where the
number of samples in the depth/stencil attachment in a subpass is a
multiple of the number of samples in the color attachments in the
subpass.
* A coverage reduction step is added to Fragment Operations which converts
a set of covered raster/depth/stencil samples to a set of color samples
that perform blending and color writes.
The coverage reduction step also includes an optional coverage modulation
step, multiplying color values by a fractional opacity corresponding to
the number of associated raster/depth/stencil samples covered.
=== New Object Types
None.
=== New Enum Constants
None.
=== New Enums
* elink:VkCoverageModulationModeNV
* elink:VkPipelineCoverageModulationStateCreateFlagsNV
=== New Structures
* slink:VkPipelineCoverageModulationStateCreateInfoNV
=== New Functions
None.
=== Issues
None.
=== Version History
* Revision 1, 2017-06-04 (Jeff Bolz)
- Internal revisions