| // Copyright 2017-2021 The Khronos Group Inc. |
| // |
| // SPDX-License-Identifier: CC-BY-4.0 |
| |
| include::{generated}/meta/{refprefix}VK_EXT_blend_operation_advanced.txt[] |
| |
| === Other Extension Metadata |
| |
| *Last Modified Date*:: |
| 2017-06-12 |
| *Contributors*:: |
| - Jeff Bolz, NVIDIA |
| |
| === Description |
| |
| 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. |
| |
| include::{generated}/interfaces/VK_EXT_blend_operation_advanced.txt[] |
| |
| === Issues |
| |
| None. |
| |
| === Version History |
| |
| * Revision 1, 2017-06-12 (Jeff Bolz) |
| - Internal revisions |
| * Revision 2, 2017-06-12 (Jeff Bolz) |
| - Internal revisions |