Blending

Blending combines the incoming source fragment’s R, G, B, and A values with the destination R, G, B, and A values of each sample stored in the framebuffer at the fragment’s (xf, yf) location. Blending is performed for each color sample covered by the fragment, rather than just once for each fragment.

Source and destination values are combined according to the blend operation, quadruplets of source and destination weighting factors determined by the blend factors, and a blend constant, to obtain a new set of R, G, B, and A values, as described below.

Blending is computed and applied separately to each color attachment used by the subpass, with separate controls for each attachment.

Prior to performing the blend operation, signed and unsigned normalized fixed-point color components undergo an implied conversion to floating-point as specified by Conversion from Normalized Fixed-Point to Floating-Point. Blending computations are treated as if carried out in floating-point, and basic blend operations are performed with a precision and dynamic range no lower than that used to represent destination components.

Note

Blending is only defined for floating-point, UNORM, SNORM, and sRGB formats. Within those formats, the implementation may only support blending on some subset of them. Which formats support blending is indicated by VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT.

The pipeline blend state is included in the VkPipelineColorBlendStateCreateInfo structure during graphics pipeline creation:

The VkPipelineColorBlendStateCreateInfo structure is defined as:

AFX_DEFINE_STRUCT(afxPipelineColorBlendConfig)
{
    afxBool logicOpEnabled; /// controls whether to apply Logical Operations.
    afxLogicOp logicOp; /// selects which logical operation to apply.
    afxNat attachmentCount; /// is the number of coloar attachments.
    VkPipelineColorBlendAttachmentState const* pAttachments; /// is an array of structures
 defining blend state for each color attachment.
    afxV4d blendConstants; /// is an array of four values used as the R, G, B, and A components of
 the blend constant that are used in blending, depending on the blend factor.
};

The VkPipelineColorBlendAttachmentState structure is defined as:

AFX_DEFINE_STRUCT(afxPipelineColorBlendAttachmentState)
{
    afxBool blendEnabled; /// controls whether blending is enabled for the corresponding color attachment. If blending is not enabled, the source fragment’s color for that attachment is passed through unmodified.
    afxBlendFactor srcColorBlendFactor; /// selects which blend factor is used to determine the source factors (Sr, Sg, Sb).
    afxBlendFactor dstColorBlendFactor; /// selects which blend factor is used to determine the destination factors (Dr, Dg, Db).
    afxBlendOp colorBlendOp; /// selects which blend operation is used to calculate the RGB values to write to the color attachment.
    afxBlendFactor srcAlphaBlendFactor; /// selects which blend factor is used to determine the source factor Sa.
    afxBlendFactor dstAlphaBlendFactor; /// selects which blend factor is used to determine the destination factor Da.
    afxBlendOp alphaBlendOp; /// selects which blend operation is used to calculate the alpha values to write to the color attachment.
    afxColorComponentFlags colorWriteMask; /// is a bitmask of bits specifying which of the R, G, B, and/or A components are enabled for writing, as described for the Color Write Mask.
};

Blend Factors

The source and destination color and alpha blending factors are selected from the enum:

typedef enum afxBlendFactor
{
    afxBlendFactor_ZERO,
    /// (0,0,0)
    /// 0

    afxBlendFactor_ONE,
    /// (1,1,1)
    /// 1

    afxBlendFactor_SRC_COLOR,
    /// (Rs0,Gs0,Bs0)
    /// As0

    afxBlendFactor_ONE_MINUS_SRC_COLOR,
    /// (1-Rs0,1-Gs0,1-Bs0)
    /// 1-As0

    afxBlendFactor_DST_COLOR,
    /// (Rd,Gd,Bd)
    /// Ad

    afxBlendFactor_ONE_MINUS_DST_COLOR,
    /// (1-Rd,1-Gd,1-Bd)
    /// 1-Ad

    afxBlendFactor_SRC_ALPHA,
    /// (As0,As0,As0)
    /// As0

    afxBlendFactor_ONE_MINUS_SRC_ALPHA,
    /// (1-As0,1-As0,1-As0)
    /// 1-As0

    afxBlendFactor_DST_ALPHA,
    /// (Ad,Ad,Ad)
    /// Ad

    afxBlendFactor_ONE_MINUS_DST_ALPHA,
    /// (1-Ad,1-Ad,1-Ad)
    /// 1-Ad

    afxBlendFactor_CONSTANT_COLOR,
    /// (Rc, Gc, Bc)
    /// Ac

    afxBlendFactor_ONE_MINUS_CONSTANT_COLOR,
    /// (1-Rc, 1-Gc, 1-Bc)
    /// 1-Ac

    afxBlendFactor_CONSTANT_ALPHA,
    /// (Ac, Ac, Ac)
    /// Ac

    afxBlendFactor_ONE_MINUS_CONSTANT_ALPHA,
    /// (1-Ac, 1-Ac, 1-Ac)
    /// 1-Ac

    afxBlendFactor_SRC_ALPHA_SATURATE,
    /// (f,f,f); f = min(As0,1-Ad)
    /// 1

    afxBlendFactor_SRC1_COLOR,
    /// (Rs1,Gs1,Bs1)
    /// As1

    afxBlendFactor_ONE_MINUS_SRC1_COLOR,
    /// (1-Rs1,1-Gs1,1-Bs1)
    /// 1-As1

    afxBlendFactor_SRC1_ALPHA,
    /// (As1,As1,As1)
    /// As1

    afxBlendFactor_ONE_MINUS_SRC1_ALPHA,
    /// (1-As1,1-As1,1-As1)
    /// 1-As1
} afxBlendFactor;

The following conventions are used:

• Rs0,Gs0,Bs0 and As0 represent the first source color R, G, B, and A components, respectively, for the fragment output location corresponding to the color attachment being blended.
• Rs1,Gs1,Bs1 and As1 represent the second source color R, G, B, and A components, respectively, used in dual source blending modes, for the fragment output location corresponding to the color attachment being blended.
• Rd,Gd,Bd and Ad represent the R, G, B, and A components of the destination color. That is, the color currently in the corresponding color attachment for this fragment/sample.
• Rc, Gc, Bc and Ac represent the blend constant R, G, B, and A components, respectively.

To dynamically set and change the blend constants, call:

void AfxCmdSetBlendConstants
(
    afxDrawScript dscr, /// is the command buffer into which the command will be recorded.
    afxReal const blendConstants[4] /// is an array of four values specifying the Rc, Gc, Bc, and Ac components of the blend constant color used in blending, depending on the blend factor.
);

This command sets blend constants for subsequent drawing commands when the graphics pipeline is created with VK_DYNAMIC_STATE_BLEND_CONSTANTS set in VkPipelineDynamicStateCreateInfo::pDynamicStates. Otherwise, this state is specified by the VkPipelineColorBlendStateCreateInfo::blendConstants values used to create the currently active pipeline.

Dual-Source Blending

Blend factors that use the secondary color input (Rs1,Gs1,Bs1,As1) (VK_BLEND_FACTOR_SRC1_COLOR, VK_BLEND_FACTOR_ONE_MINUS_SRC1_COLOR, VK_BLEND_FACTOR_SRC1_ALPHA, and VK_BLEND_FACTOR_ONE_MINUS_SRC1_ALPHA) may consume implementation resources that could otherwise be used for rendering to multiple color attachments. Therefore, the number of color attachments that can be used in a framebuffer may be lower when using dual-source blending.

Dual-source blending is only supported if the dualSrcBlend feature is enabled.

The maximum number of color attachments that can be used in a subpass when using dual-source blending functions is implementation-dependent and is reported as the maxFragmentDualSrcAttachments member of VkPhysicalDeviceLimits.

Color outputs can be bound to the first and second inputs of the blender using the Index decoration, as described in Fragment Output Interface. If the second color input to the blender is not written in the shader, or if no output is bound to the second input of a blender, the value of the second input is undefined.

Blend Operations

Once the source and destination blend factors have been selected, they along with the source and destination components are passed to the blending operations. RGB and alpha components can use different operations. Possible values of afxBlendOp, specifying the operations, are:

typedef enum afxBlendOp
{
    afxBlendOp_ADD,
    /// R = Rs0 × Sr + Rd × Dr
    /// G = Gs0 × Sg + Gd × Dg
    /// B = Bs0 × Sb + Bd × Db
    /// A = As0 × Sa  + Ad × Da

    afxBlendOp_SUB,
    /// R = Rs0 × Sr - Rd × Dr
    /// G = Gs0 × Sg - Gd × Dg
    /// B = Bs0 × Sb - Bd × Db
    /// A = As0 × Sa - Ad × Da

    afxBlendOp_REV_SUB,
    /// R = Rd × Dr - Rs0 × Sr
    /// G = Gd × Dg - Gs0 × Sg
    /// B = Bd × Db - Bs0 × Sb
    /// A = Ad × Da - As0 × Sa

    afxBlendOp_MIN,
    /// R = min(Rs0,Rd)
    /// G = min(Gs0,Gd)
    /// B = min(Bs0,Bd)
    /// A = min(As0,Ad)

    afxBlendOp_MAX,
    /// R = max(Rs0,Rd)
    /// G = max(Gs0,Gd)
    /// B = max(Bs0,Bd)
    /// A = max(As0,Ad)
} afxBlendOp;

The following conventions are used:

• Rs0, Gs0, Bs0 and As0 represent the first source color R, G, B, and A components, respectively.
• Rd, Gd, Bd and Ad represent the R, G, B, and A components of the destination color. That is, the color currently in the corresponding color attachment for this fragment/sample.
• Sr, Sg, Sb and Sa represent the source blend factor R, G, B, and A components, respectively.
• Dr, Dg, Db and Da represent the destination blend factor R, G, B, and A components, respectively.

The blending operation produces a new set of values R, G, B and A, which are written to the framebuffer attachment. If blending is not enabled for this attachment, then R, G, B and A are assigned Rs0, Gs0, Bs0 and As0, respectively.

If the color attachment is fixed-point, the components of the source and destination values and blend factors are each clamped to [0,1] or [-1,1] respectively for an unsigned normalized or signed normalized color attachment prior to evaluating the blend operations. If the color attachment is floating-point, no clamping occurs.

If the numeric format of a framebuffer attachment uses sRGB encoding, the R, G, and B destination color values (after conversion from fixed-point to floating-point) are considered to be encoded for the sRGB color space and hence are linearized prior to their use in blending. Each R, G, and B component is converted from nonlinear to linear as described in the “sRGB EOTF” section of the Khronos Data Format Specification. If the format is not sRGB, no linearization is performed.

If the numeric format of a framebuffer attachment uses sRGB encoding, then the final R, G and B values are converted into the nonlinear sRGB representation before being written to the framebuffer attachment as described in the “sRGB EOTF -1” section of the Khronos Data Format Specification.

If the numeric format of a framebuffer color attachment is not sRGB encoded then the resulting cs values for R, G and B are unmodified. The value of A is never sRGB encoded. That is, the alpha component is always stored in memory as linear.

If the framebuffer color attachment is VK_ATTACHMENT_UNUSED, no writes are performed through that attachment. Writes are not performed to framebuffer color attachments greater than or equal to the VkSubpassDescription::colorAttachmentCount or VkSubpassDescription2::colorAttachmentCount value.