status-im/Vulkan-Docs
2
0
Fork 0
mirror of https://github.com/status-im/Vulkan-Docs.git synced 2025-02-25 12:35:11 +00:00
Code Issues Projects Releases Wiki Activity
Vulkan-Docs/appendices/VK_EXT_blend_operation_advanced.txt
Jon Leech 59750fe4c7 Change log for August 25, 2019 Vulkan 1.1.121 spec update: 
* Update release number to 121.

Github Issues:

  * Add missing `structextends` attribute in `vk.xml` for
    slink:VkPhysicalDevicePipelineExecutablePropertiesFeaturesKHR (public
    issue 1018).
  * Change attributes of flink:vkCmdCopyAccelerationStructureNV,
    flink:vkCmdWriteAccelerationStructuresPropertiesNV,
    flink:vkCmdBuildAccelerationStructureNV, and flink:vkCmdTraceRaysNV to
    require that these commands execute outside renderpasses (public issue
    1021).
  * Add an issue to the `<<VK_EXT_buffer_device_address>>` appendix
    discussing the introduction of new names and aliasing by equivalent old
    names (public pull request 1024).

Internal Issues:

  * Protect the `VK_KHR_sampler_mirror_clamp_to_edge` extension with
    asciidoctor conditionals, and remove it from the core-only specification
    builds, where it had previously been force-included in the Makefile. It
    is now treated like any other extension (internal issue 1776).
  * Edit some asciidoctor anchor names starting with `features-features-` to
    just start with `features-`, since the old chapters was split into 3
    pieces. There are still some mild naming inconsistencies with anchors
    which may be addressed in the future (internal issue 1792).
  * Add `KHR` alias for the non-suffixed extension token
    ename:VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE, for compatibility
    with naming rules for extensions (internal issue 1796).
  * Clarify requirements for external memory in NOTEs for
    sname:VkExternalMemoryBufferCreateInfo, and valid usage statements for
    flink:vkBindBufferMemory, slink:VkBindBufferMemoryInfo,
    flink:vkBindImageMemory, and slink:VkBindImageMemoryInfo (internal merge
    request 3301).
  * Make extension version numbers in `vk.xml` and extension appendices
    consistent. In a few cases, we could not recover history at this
    granularity, and left the summary of a version's change undefined
    (internal merge request 3323).
  * Fix invocation of `CodeInlineMacro` in the Ruby extension backing the
    `code:` macro, which was delegating to the wrong base class (internal
    merge request 3331).
  * Modify `reg.py` to do a better job of recognizing equivalent <enum>
    definitions.
  * Add a `sortorder` attribute to XML feature and extension tags.

New Extensions

  * `<<VK_AMD_device_coherent_memory>>`
2019-08-25 03:57:09 -07:00

177 lines
7.1 KiB
Plaintext
Raw Blame History

include::meta/VK_EXT_blend_operation_advanced.txt[]
*Last Modified Date*::
2017-06-12
*Contributors*::
- Jeff Bolz, NVIDIA
This extension adds a number of "`advanced`" blending operations that can:
be used to perform new color blending operations, many of which are more
complex than the standard blend modes provided by unextended Vulkan.
This extension requires different styles of usage, depending on the level of
hardware support and the enabled features:
- If
slink:VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT::pname:advancedBlendCoherentOperations
is ename:VK_FALSE, the new blending operations are supported, but a
memory dependency must: separate each advanced blend operation on a
given sample.
ename:VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT is used to
synchronize reads using advanced blend operations.
- If
slink:VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT::pname:advancedBlendCoherentOperations
is ename:VK_TRUE, advanced blend operations obey primitive order just
like basic blend operations.
In unextended Vulkan, the set of blending operations is limited, and can: be
expressed very simply.
The ename:VK_BLEND_OP_MIN and ename:VK_BLEND_OP_MAX blend operations simply
compute component-wise minimums or maximums of source and destination color
components.
The ename:VK_BLEND_OP_ADD, ename:VK_BLEND_OP_SUBTRACT, and
ename:VK_BLEND_OP_REVERSE_SUBTRACT modes multiply the source and destination
colors by source and destination factors and either add the two products
together or subtract one from the other.
This limited set of operations supports many common blending operations but
precludes the use of more sophisticated transparency and blending operations
commonly available in many dedicated imaging APIs.
This extension provides a number of new "`advanced`" blending operations.
Unlike traditional blending operations using ename:VK_BLEND_OP_ADD, these
blending equations do not use source and destination factors specified by
elink:VkBlendFactor.
Instead, each blend operation specifies a complete equation based on the
source and destination colors.
These new blend operations are used for both RGB and alpha components; they
must: not be used to perform separate RGB and alpha blending (via different
values of color and alpha elink:VkBlendOp).
These blending operations are performed using premultiplied colors, where
RGB colors can: be considered premultiplied or non-premultiplied by alpha,
according to the pname:srcPremultiplied and pname:dstPremultiplied members
of slink:VkPipelineColorBlendAdvancedStateCreateInfoEXT.
If a color is considered non-premultiplied, the (R,G,B) color components are
multiplied by the alpha component prior to blending.
For non-premultiplied color components in the range [eq]#[0,1]#, the
corresponding premultiplied color component would have values in the range
[eq]#[0 {times} A, 1 {times} A]#.
Many of these advanced blending equations are formulated where the result of
blending source and destination colors with partial coverage have three
separate contributions: from the portions covered by both the source and the
destination, from the portion covered only by the source, and from the
portion covered only by the destination.
The blend parameter
slink:VkPipelineColorBlendAdvancedStateCreateInfoEXT::pname:blendOverlap
can: be used to specify a correlation between source and destination pixel
coverage.
If set to ename:VK_BLEND_OVERLAP_CONJOINT_EXT, the source and destination
are considered to have maximal overlap, as would be the case if drawing two
objects on top of each other.
If set to ename:VK_BLEND_OVERLAP_DISJOINT_EXT, the source and destination
are considered to have minimal overlap, as would be the case when rendering
a complex polygon tessellated into individual non-intersecting triangles.
If set to ename:VK_BLEND_OVERLAP_UNCORRELATED_EXT, the source and
destination coverage are assumed to have no spatial correlation within the
pixel.
In addition to the coherency issues on implementations not supporting
pname:advancedBlendCoherentOperations, this extension has several
limitations worth noting.
First, the new blend operations have a limit on the number of color
attachments they can: be used with, as indicated by
slink:VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT::pname:advancedBlendMaxColorAttachments.
Additionally, blending precision may: be limited to 16-bit floating-point,
which may: result in a loss of precision and dynamic range for framebuffer
formats with 32-bit floating-point components, and in a loss of precision
for formats with 12- and 16-bit signed or unsigned normalized integer
components.
=== New Object Types
None.
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BLEND_OPERATION_ADVANCED_FEATURES_EXT
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BLEND_OPERATION_ADVANCED_PROPERTIES_EXT
** ename:VK_STRUCTURE_TYPE_PIPELINE_COLOR_BLEND_ADVANCED_STATE_CREATE_INFO_EXT
* Extending elink:VkAccessFlagBits:
** ename:VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT
* Extending elink:VkBlendOp:
** ename:VK_BLEND_OP_ZERO_EXT
** ename:VK_BLEND_OP_SRC_EXT
** ename:VK_BLEND_OP_DST_EXT
** ename:VK_BLEND_OP_SRC_OVER_EXT
** ename:VK_BLEND_OP_DST_OVER_EXT
** ename:VK_BLEND_OP_SRC_IN_EXT
** ename:VK_BLEND_OP_DST_IN_EXT
** ename:VK_BLEND_OP_SRC_OUT_EXT
** ename:VK_BLEND_OP_DST_OUT_EXT
** ename:VK_BLEND_OP_SRC_ATOP_EXT
** ename:VK_BLEND_OP_DST_ATOP_EXT
** ename:VK_BLEND_OP_XOR_EXT
** ename:VK_BLEND_OP_MULTIPLY_EXT
** ename:VK_BLEND_OP_SCREEN_EXT
** ename:VK_BLEND_OP_OVERLAY_EXT
** ename:VK_BLEND_OP_DARKEN_EXT
** ename:VK_BLEND_OP_LIGHTEN_EXT
** ename:VK_BLEND_OP_COLORDODGE_EXT
** ename:VK_BLEND_OP_COLORBURN_EXT
** ename:VK_BLEND_OP_HARDLIGHT_EXT
** ename:VK_BLEND_OP_SOFTLIGHT_EXT
** ename:VK_BLEND_OP_DIFFERENCE_EXT
** ename:VK_BLEND_OP_EXCLUSION_EXT
** ename:VK_BLEND_OP_INVERT_EXT
** ename:VK_BLEND_OP_INVERT_RGB_EXT
** ename:VK_BLEND_OP_LINEARDODGE_EXT
** ename:VK_BLEND_OP_LINEARBURN_EXT
** ename:VK_BLEND_OP_VIVIDLIGHT_EXT
** ename:VK_BLEND_OP_LINEARLIGHT_EXT
** ename:VK_BLEND_OP_PINLIGHT_EXT
** ename:VK_BLEND_OP_HARDMIX_EXT
** ename:VK_BLEND_OP_HSL_HUE_EXT
** ename:VK_BLEND_OP_HSL_SATURATION_EXT
** ename:VK_BLEND_OP_HSL_COLOR_EXT
** ename:VK_BLEND_OP_HSL_LUMINOSITY_EXT
** ename:VK_BLEND_OP_PLUS_EXT
** ename:VK_BLEND_OP_PLUS_CLAMPED_EXT
** ename:VK_BLEND_OP_PLUS_CLAMPED_ALPHA_EXT
** ename:VK_BLEND_OP_PLUS_DARKER_EXT
** ename:VK_BLEND_OP_MINUS_EXT
** ename:VK_BLEND_OP_MINUS_CLAMPED_EXT
** ename:VK_BLEND_OP_CONTRAST_EXT
** ename:VK_BLEND_OP_INVERT_OVG_EXT
** ename:VK_BLEND_OP_RED_EXT
** ename:VK_BLEND_OP_GREEN_EXT
** ename:VK_BLEND_OP_BLUE_EXT
=== New Enums
* elink:VkBlendOverlapEXT
=== New Structures
* slink:VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT
* slink:VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT
* slink:VkPipelineColorBlendAdvancedStateCreateInfoEXT
=== New Functions
None.
=== Issues
None.
=== Version History
* Revision 1, 2017-06-12 (Jeff Bolz)
- Internal revisions
* Revision 2, 2017-06-12 (Jeff Bolz)
- Internal revisions
Reference in New Issue View Git Blame Copy Permalink