Vulkan-Docs/doc/specs/vulkan/appendices/VK_EXT_blend_operation_adva...

185 lines
7.4 KiB
Plaintext
Raw Normal View History

Change log for June 24, 2017 Vulkan 1.0.53 spec update: * Bump API patch number and header version number to 53 for this update. Github Issues: Internal Issues: * Clarify mappings of coordinates for mutable, compatible image views in slink:VkImageViewCreateInfo (internal issue 815). * Make ename:VK_BIND_SFR_BIT require a logical device with multiple physical devices, so that standard sparse image block dimensions are only required on systems that support multi-GPU (internal issue 835). * Convert all files from use of // refBegin .. // refEnd comments to delimit ref pages, to use of open blocks, and update style guide accordingly (internal issue 839). * Add valid usage for slink:VkWriteDescriptorSet when performing updates to a ename:VK_STORAGE_IMAGE descriptor with layout ename:VK_IMAGE_LAYOUT_GENERAL. * Add a hack to the validity generator script to support an odd interaction between flink:vkCmdFillBuffer and an extension (internal issue 853). * Remove redundant text describing slink:VkBufferCreateInfo::pname:usage, which was already covered by implicit valid usage (internal issue 854). * Update implicit validity generator script to properly handle the pname:sType and pname:pNext members of "returnedonly" structures (internal issue 874). * Note that slink:VkApplicationInfo::pname:pApplicationName & slink:VkApplicationInfo::pname:pEngineName are optional, and add missing implicit valid usage statements for flink:vkDestroyInstance. * Added missing valid usage for flink:vkCmdWriteTimestamp to require a timestamp query pool. * Simplify and/or split "`non-atomic`" valid usage statements. New Extensions: * `VK_AMD_gpu_shader_int16` * `VK_EXT_blend_operation_advanced` * `VK_EXT_sampler_filter_minmax` * `VK_NV_framebuffer_mixed_samples` ----------------------------------------------------- Note: the 1.0.52 spec wasn't published on github, so the 1.0.53 release combines both change sets. ----------------------------------------------------- Change log for June 13, 2017 Vulkan 1.0.52 spec update: * Bump API patch number and header version number to 52 for this update. Github Issues: Internal Issues: * Clarify behavior when non-coherent memory has <<memory-device-unmap-does-not-flush, not been flushed before being unmapped>> (internal issue 819). * Fix description of code:WorkgroupSize builtin to note it decorates an object, not a variable (internal issue 836). * Fix asciidoc attributes so that trailing '{plus}' symbols in [eq] style equations are rendered properly (internal issue 845). * Add language to the "`Extension Handles, Objects, Enums, and Typedefs`" section of the Procedures and Conventions document stating that any new handle type requires a corresponding entry in the elink:VkObjectType enumerated type (internal issue 856). * Update style guide to use slink macro for Vulkan handle type names, and define narrow conditions under which to use the *name and *text macros instead of *link (internal issue 886). * Add a dependency of the <<VK_KHX_device_group,VK_KHX_device_group>> extension on VK_KHX_device_group_creation to +vk.xml+ and the extension appendix. * Change the copyright on Vulkan specification asciidoc *source* files to CC-BY 4.0, and update the proprietary Khronos copyright applied to the generated *output* formats (internal issue 327). This enables broader re-use and modification of the Vulkan specification sources, while not affecting the Reciprocal IP License between Vulkan Adopters and Working Group Members. New Extensions: * `VK_NV_fill_rectangle` * `VK_NV_fragment_coverage_to_color`
2017-06-27 02:32:10 +00:00
[[VK_EXT_blend_operation_advanced]]
== VK_EXT_blend_operation_advanced
*Name String*::
VK_EXT_blend_operation_advanced
*Extension Type*::
Device extension
*Registered Extension Number*::
149
*Status*::
Complete
*Last Modified Data*::
2017-06-12
*Revision*::
2
*Dependencies*::
- This extension is written against version 1.0 of the Vulkan API.
- This extension requires Vulkan 1.0.
*Contributors*::
- Jeff Bolz, NVIDIA
*Contact*::
- Jeff Bolz (jbolz 'at' nvidia.com)
*Overview*::
+
--
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 feature enable:
- 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
* Revisions 1-2, 2017-06-12 (Jeff Bolz)
- Internal revisions