1// Copyright (c) 2015-2018 Khronos Group. This work is licensed under a 2// Creative Commons Attribution 4.0 International License; see 3// http://creativecommons.org/licenses/by/4.0/ 4 5[[framebuffer]] 6= The Framebuffer 7 8 9[[framebuffer-blending]] 10== Blending 11 12Blending combines the incoming _source_ fragment's R, G, B, and A values 13with the _destination_ R, G, B, and A values of each sample stored in the 14framebuffer at the fragment's [eq]#(x~f~,y~f~)# location. 15Blending is performed for each pixel sample, rather than just once for each 16fragment. 17 18Source and destination values are combined according to the 19<<framebuffer-blendoperations,blend operation>>, quadruplets of source and 20destination weighting factors determined by the <<framebuffer-blendfactors, 21blend factors>>, and a <<framebuffer-blendconstants,blend constant>>, to 22obtain a new set of R, G, B, and A values, as described below. 23 24Blending is computed and applied separately to each color attachment used by 25the subpass, with separate controls for each attachment. 26 27Prior to performing the blend operation, signed and unsigned normalized 28fixed-point color components undergo an implied conversion to floating-point 29as specified by <<fundamentals-fixedfpconv,Conversion from Normalized 30Fixed-Point to Floating-Point>>. 31Blending computations are treated as if carried out in floating-point, and 32basic blend operations are performed with a precision and dynamic range no 33lower than that used to represent destination components. 34ifdef::VK_EXT_blend_operation_advanced[] 35<<framebuffer-blend-advanced,Advanced blending operations>> are performed 36with a precision and dynamic range no lower than the smaller of that used to 37represent destination components or that used to represent 16-bit 38floating-point values. 39endif::VK_EXT_blend_operation_advanced[] 40 41Blending applies only to fixed-point and floating-point color attachments. 42If the color attachment has an integer format, blending is not applied. 43 44The pipeline blend state is included in the 45sname:VkPipelineColorBlendStateCreateInfo structure during graphics pipeline 46creation: 47 48[open,refpage='VkPipelineColorBlendStateCreateInfo',desc='Structure specifying parameters of a newly created pipeline color blend state',type='structs'] 49-- 50 51The sname:VkPipelineColorBlendStateCreateInfo structure is defined as: 52 53include::../api/structs/VkPipelineColorBlendStateCreateInfo.txt[] 54 55 * pname:sType is the type of this structure. 56 * pname:pNext is `NULL` or a pointer to an extension-specific structure. 57 * pname:flags is reserved for future use. 58 * pname:logicOpEnable controls whether to apply <<framebuffer-logicop, 59 Logical Operations>>. 60 * pname:logicOp selects which logical operation to apply. 61 * pname:attachmentCount is the number of 62 sname:VkPipelineColorBlendAttachmentState elements in 63 pname:pAttachments. 64 This value must: equal the pname:colorAttachmentCount for the subpass in 65 which this pipeline is used. 66 * pname:pAttachments: is a pointer to array of per target attachment 67 states. 68 * pname:blendConstants is an array of four values used as the R, G, B, and 69 A components of the blend constant that are used in blending, depending 70 on the <<framebuffer-blendfactors,blend factor>>. 71 72Each element of the pname:pAttachments array is a 73slink:VkPipelineColorBlendAttachmentState structure specifying per-target 74blending state for each individual color attachment. 75If the <<features-features-independentBlend,independent blending>> feature 76is not enabled on the device, all slink:VkPipelineColorBlendAttachmentState 77elements in the pname:pAttachments array must: be identical. 78 79.Valid Usage 80**** 81 * [[VUID-VkPipelineColorBlendStateCreateInfo-pAttachments-00605]] 82 If the <<features-features-independentBlend,independent blending>> 83 feature is not enabled, all elements of pname:pAttachments must: be 84 identical 85 * [[VUID-VkPipelineColorBlendStateCreateInfo-logicOpEnable-00606]] 86 If the <<features-features-logicOp,logic operations>> feature is not 87 enabled, pname:logicOpEnable must: be ename:VK_FALSE 88 * [[VUID-VkPipelineColorBlendStateCreateInfo-logicOpEnable-00607]] 89 If pname:logicOpEnable is ename:VK_TRUE, pname:logicOp must: be a valid 90 elink:VkLogicOp value 91**** 92 93include::../validity/structs/VkPipelineColorBlendStateCreateInfo.txt[] 94-- 95 96[open,refpage='VkPipelineColorBlendStateCreateFlags',desc='Reserved for future use',type='enums'] 97-- 98include::../api/flags/VkPipelineColorBlendStateCreateFlags.txt[] 99 100sname:VkPipelineColorBlendStateCreateFlags is a bitmask type for setting a 101mask, but is currently reserved for future use. 102-- 103 104[open,refpage='VkPipelineColorBlendAttachmentState',desc='Structure specifying a pipeline color blend attachment state',type='structs'] 105-- 106 107The sname:VkPipelineColorBlendAttachmentState structure is defined as: 108 109include::../api/structs/VkPipelineColorBlendAttachmentState.txt[] 110 111 * pname:blendEnable controls whether blending is enabled for the 112 corresponding color attachment. 113 If blending is not enabled, the source fragment's color for that 114 attachment is passed through unmodified. 115 * pname:srcColorBlendFactor selects which blend factor is used to 116 determine the source factors [eq]#(S~r~,S~g~,S~b~)#. 117 * pname:dstColorBlendFactor selects which blend factor is used to 118 determine the destination factors [eq]#(D~r~,D~g~,D~b~)#. 119 * pname:colorBlendOp selects which blend operation is used to calculate 120 the RGB values to write to the color attachment. 121 * pname:srcAlphaBlendFactor selects which blend factor is used to 122 determine the source factor [eq]#S~a~#. 123 * pname:dstAlphaBlendFactor selects which blend factor is used to 124 determine the destination factor [eq]#D~a~#. 125 * pname:alphaBlendOp selects which blend operation is use to calculate the 126 alpha values to write to the color attachment. 127 * pname:colorWriteMask is a bitmask of elink:VkColorComponentFlagBits 128 specifying which of the R, G, B, and/or A components are enabled for 129 writing, as described for the <<framebuffer-color-write-mask,Color Write 130 Mask>>. 131 132.Valid Usage 133**** 134 * [[VUID-VkPipelineColorBlendAttachmentState-srcColorBlendFactor-00608]] 135 If the <<features-features-dualSrcBlend,dual source blending>> feature 136 is not enabled, pname:srcColorBlendFactor must: not be 137 ename:VK_BLEND_FACTOR_SRC1_COLOR, 138 ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_COLOR, 139 ename:VK_BLEND_FACTOR_SRC1_ALPHA, or 140 ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_ALPHA 141 * [[VUID-VkPipelineColorBlendAttachmentState-dstColorBlendFactor-00609]] 142 If the <<features-features-dualSrcBlend,dual source blending>> feature 143 is not enabled, pname:dstColorBlendFactor must: not be 144 ename:VK_BLEND_FACTOR_SRC1_COLOR, 145 ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_COLOR, 146 ename:VK_BLEND_FACTOR_SRC1_ALPHA, or 147 ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_ALPHA 148 * [[VUID-VkPipelineColorBlendAttachmentState-srcAlphaBlendFactor-00610]] 149 If the <<features-features-dualSrcBlend,dual source blending>> feature 150 is not enabled, pname:srcAlphaBlendFactor must: not be 151 ename:VK_BLEND_FACTOR_SRC1_COLOR, 152 ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_COLOR, 153 ename:VK_BLEND_FACTOR_SRC1_ALPHA, or 154 ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_ALPHA 155 * [[VUID-VkPipelineColorBlendAttachmentState-dstAlphaBlendFactor-00611]] 156 If the <<features-features-dualSrcBlend,dual source blending>> feature 157 is not enabled, pname:dstAlphaBlendFactor must: not be 158 ename:VK_BLEND_FACTOR_SRC1_COLOR, 159 ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_COLOR, 160 ename:VK_BLEND_FACTOR_SRC1_ALPHA, or 161 ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_ALPHA 162ifdef::VK_EXT_blend_operation_advanced[] 163 * [[VUID-VkPipelineColorBlendAttachmentState-colorBlendOp-01406]] 164 If either of pname:colorBlendOp or pname:alphaBlendOp is an 165 <<framebuffer-blend-advanced,advanced blend operation>>, then 166 pname:colorBlendOp must: equal pname:alphaBlendOp 167 * [[VUID-VkPipelineColorBlendAttachmentState-advancedBlendIndependentBlend-01407]] 168 If 169 slink:VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT::pname:advancedBlendIndependentBlend 170 is ename:VK_FALSE and pname:colorBlendOp is an 171 <<framebuffer-blend-advanced,advanced blend operation>>, then 172 pname:colorBlendOp must: be the same for all attachments. 173 * [[VUID-VkPipelineColorBlendAttachmentState-advancedBlendIndependentBlend-01408]] 174 If 175 slink:VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT::pname:advancedBlendIndependentBlend 176 is ename:VK_FALSE and pname:alphaBlendOp is an 177 <<framebuffer-blend-advanced,advanced blend operation>>, then 178 pname:alphaBlendOp must: be the same for all attachments. 179 * [[VUID-VkPipelineColorBlendAttachmentState-advancedBlendAllOperations-01409]] 180 If 181 slink:VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT::pname:advancedBlendAllOperations 182 is ename:VK_FALSE, then pname:colorBlendOp must: not be 183 ename:VK_BLEND_OP_ZERO_EXT, ename:VK_BLEND_OP_SRC_EXT, 184 ename:VK_BLEND_OP_DST_EXT, ename:VK_BLEND_OP_SRC_OVER_EXT, 185 ename:VK_BLEND_OP_DST_OVER_EXT, ename:VK_BLEND_OP_SRC_IN_EXT, 186 ename:VK_BLEND_OP_DST_IN_EXT, ename:VK_BLEND_OP_SRC_OUT_EXT, 187 ename:VK_BLEND_OP_DST_OUT_EXT, ename:VK_BLEND_OP_SRC_ATOP_EXT, 188 ename:VK_BLEND_OP_DST_ATOP_EXT, ename:VK_BLEND_OP_XOR_EXT, 189 ename:VK_BLEND_OP_INVERT_EXT, ename:VK_BLEND_OP_INVERT_RGB_EXT, 190 ename:VK_BLEND_OP_LINEARDODGE_EXT, ename:VK_BLEND_OP_LINEARBURN_EXT, 191 ename:VK_BLEND_OP_VIVIDLIGHT_EXT, ename:VK_BLEND_OP_LINEARLIGHT_EXT, 192 ename:VK_BLEND_OP_PINLIGHT_EXT, ename:VK_BLEND_OP_HARDMIX_EXT, 193 ename:VK_BLEND_OP_PLUS_EXT, ename:VK_BLEND_OP_PLUS_CLAMPED_EXT, 194 ename:VK_BLEND_OP_PLUS_CLAMPED_ALPHA_EXT, 195 ename:VK_BLEND_OP_PLUS_DARKER_EXT, ename:VK_BLEND_OP_MINUS_EXT, 196 ename:VK_BLEND_OP_MINUS_CLAMPED_EXT, ename:VK_BLEND_OP_CONTRAST_EXT, 197 ename:VK_BLEND_OP_INVERT_OVG_EXT, ename:VK_BLEND_OP_RED_EXT, 198 ename:VK_BLEND_OP_GREEN_EXT, or ename:VK_BLEND_OP_BLUE_EXT 199 * [[VUID-VkPipelineColorBlendAttachmentState-colorBlendOp-01410]] 200 If pname:colorBlendOp or pname:alphaBlendOp is an 201 <<framebuffer-blend-advanced,advanced blend operation>>, then 202 slink:VkSubpassDescription::pname:colorAttachmentCount of the subpass 203 this pipeline is compiled against must: be less than or equal to 204 slink:VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT::advancedBlendMaxColorAttachments 205endif::VK_EXT_blend_operation_advanced[] 206**** 207 208include::../validity/structs/VkPipelineColorBlendAttachmentState.txt[] 209-- 210 211 212[[framebuffer-blendfactors]] 213=== Blend Factors 214 215[open,refpage='VkBlendFactor',desc='Framebuffer blending factors',type='enums'] 216-- 217 218The source and destination color and alpha blending factors are selected 219from the enum: 220 221include::../api/enums/VkBlendFactor.txt[] 222 223The semantics of each enum value is described in the table below: 224 225.Blend Factors 226[width="100%",options="header",align="center",cols="59%,28%,13%"] 227|==== 228|elink:VkBlendFactor | RGB Blend Factors [eq]#(S~r~,S~g~,S~b~)# or [eq]#(D~r~,D~g~,D~b~)# | Alpha Blend Factor ([eq]#S~a~# or [eq]#D~a~#) 229|ename:VK_BLEND_FACTOR_ZERO | [eq]#(0,0,0)# | [eq]#0# 230|ename:VK_BLEND_FACTOR_ONE | [eq]#(1,1,1)# | [eq]#1# 231|ename:VK_BLEND_FACTOR_SRC_COLOR | [eq]#(R~s0~,G~s0~,B~s0~)# | [eq]#A~s0~# 232|ename:VK_BLEND_FACTOR_ONE_MINUS_SRC_COLOR | [eq]#(1-R~s0~,1-G~s0~,1-B~s0~)# | [eq]#1-A~s0~# 233|ename:VK_BLEND_FACTOR_DST_COLOR | [eq]#(R~d~,G~d~,B~d~)# | [eq]#A~d~# 234|ename:VK_BLEND_FACTOR_ONE_MINUS_DST_COLOR | [eq]#(1-R~d~,1-G~d~,1-B~d~)# | [eq]#1-A~d~# 235|ename:VK_BLEND_FACTOR_SRC_ALPHA | [eq]#(A~s0~,A~s0~,A~s0~)# | [eq]#A~s0~# 236|ename:VK_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA | [eq]#(1-A~s0~,1-A~s0~,1-A~s0~)# | [eq]#1-A~s0~# 237|ename:VK_BLEND_FACTOR_DST_ALPHA | [eq]#(A~d~,A~d~,A~d~)# | [eq]#A~d~# 238|ename:VK_BLEND_FACTOR_ONE_MINUS_DST_ALPHA | [eq]#(1-A~d~,1-A~d~,1-A~d~)# | [eq]#1-A~d~# 239|ename:VK_BLEND_FACTOR_CONSTANT_COLOR | [eq]#(R~c~,G~c~,B~c~)# | [eq]#A~c~# 240|ename:VK_BLEND_FACTOR_ONE_MINUS_CONSTANT_COLOR | [eq]#(1-R~c~,1-G~c~,1-B~c~)# | [eq]#1-A~c~# 241|ename:VK_BLEND_FACTOR_CONSTANT_ALPHA | [eq]#(A~c~,A~c~,A~c~)# | [eq]#A~c~# 242|ename:VK_BLEND_FACTOR_ONE_MINUS_CONSTANT_ALPHA | [eq]#(1-A~c~,1-A~c~,1-A~c~)# | [eq]#1-A~c~# 243|ename:VK_BLEND_FACTOR_SRC_ALPHA_SATURATE | [eq]#(f,f,f)#; [eq]#f = min(A~s0~,1-A~d~)# | [eq]#1# 244|ename:VK_BLEND_FACTOR_SRC1_COLOR | [eq]#(R~s1~,G~s1~,B~s1~)# | [eq]#A~s1~# 245|ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_COLOR | [eq]#(1-R~s1~,1-G~s1~,1-B~s1~)# | [eq]#1-A~s1~# 246|ename:VK_BLEND_FACTOR_SRC1_ALPHA | [eq]#(A~s1~,A~s1~,A~s1~)# | [eq]#A~s1~# 247|ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_ALPHA | [eq]#(1-A~s1~,1-A~s1~,1-A~s1~)# | [eq]#1-A~s1~# 248|==== 249 250In this table, the following conventions are used: 251 252 * [eq]#R~s0~,G~s0~,B~s0~# and [eq]#A~s0~# represent the first source color 253 R, G, B, and A components, respectively, for the fragment output 254 location corresponding to the color attachment being blended. 255 * [eq]#R~s1~,G~s1~,B~s1~# and [eq]#A~s1~# represent the second source 256 color R, G, B, and A components, respectively, used in dual source 257 blending modes, for the fragment output location corresponding to the 258 color attachment being blended. 259 * [eq]#R~d~,G~d~,B~d~# and [eq]#A~d~# represent the R, G, B, and A 260 components of the destination color. 261 That is, the color currently in the corresponding color attachment for 262 this fragment/sample. 263 * [eq]#R~c~,G~c~,B~c~# and [eq]#A~c~# represent the blend constant R, G, 264 B, and A components, respectively. 265 266-- 267 268[[framebuffer-blendconstants]] 269If the pipeline state object is created without the 270ename:VK_DYNAMIC_STATE_BLEND_CONSTANTS dynamic state enabled then the _blend 271constant_ [eq]#(R~c~,G~c~,B~c~,A~c~)# is specified via the 272pname:blendConstants member of slink:VkPipelineColorBlendStateCreateInfo. 273 274[open,refpage='vkCmdSetBlendConstants',desc='Set the values of blend constants',type='protos'] 275-- 276 277Otherwise, to dynamically set and change the blend constant, call: 278 279include::../api/protos/vkCmdSetBlendConstants.txt[] 280 281 * pname:commandBuffer is the command buffer into which the command will be 282 recorded. 283 * pname:blendConstants is an array of four values specifying the R, G, B, 284 and A components of the blend constant color used in blending, depending 285 on the <<framebuffer-blendfactors,blend factor>>. 286 287.Valid Usage 288**** 289 * [[VUID-vkCmdSetBlendConstants-None-00612]] 290 The bound graphics pipeline must: have been created with the 291 ename:VK_DYNAMIC_STATE_BLEND_CONSTANTS dynamic state enabled 292**** 293 294include::../validity/protos/vkCmdSetBlendConstants.txt[] 295-- 296 297 298[[framebuffer-dsb]] 299=== Dual-Source Blending 300 301Blend factors that use the secondary color input 302[eq]#(R~s1~,G~s1~,B~s1~,A~s1~)# (ename:VK_BLEND_FACTOR_SRC1_COLOR, 303ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_COLOR, 304ename:VK_BLEND_FACTOR_SRC1_ALPHA, and 305ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_ALPHA) may: consume implementation 306resources that could otherwise be used for rendering to multiple color 307attachments. 308Therefore, the number of color attachments that can: be used in a 309framebuffer may: be lower when using dual-source blending. 310 311Dual-source blending is only supported if the 312<<features-features-dualSrcBlend,pname:dualSrcBlend>> feature is enabled. 313 314The maximum number of color attachments that can: be used in a subpass when 315using dual-source blending functions is implementation-dependent and is 316reported as the pname:maxFragmentDualSrcAttachments member of 317sname:VkPhysicalDeviceLimits. 318 319When using a fragment shader with dual-source blending functions, the color 320outputs are bound to the first and second inputs of the blender using the 321code:Index decoration, as described in <<interfaces-fragmentoutput,Fragment 322Output Interface>>. 323If the second color input to the blender is not written in the shader, or if 324no output is bound to the second input of a blender, the result of the 325blending operation is not defined. 326 327 328[[framebuffer-blendoperations]] 329=== Blend Operations 330 331[open,refpage='VkBlendOp',desc='Framebuffer blending operations',type='enums'] 332-- 333 334Once the source and destination blend factors have been selected, they along 335with the source and destination components are passed to the blending 336operations. 337RGB and alpha components can: use different operations. 338Possible values of elink:VkBlendOp, specifying the operations, are: 339 340 341include::../api/enums/VkBlendOp.txt[] 342 343<<< 344 345The semantics of each basic blend operations is described in the table 346below: 347 348.Basic Blend Operations 349[width="100%",cols="45%,30%,25%",options="header",align="center"] 350|==== 351|elink:VkBlendOp | RGB Components | Alpha Component 352 353|ename:VK_BLEND_OP_ADD 354| [eq]#R = R~s0~ {times} S~r~ {plus} R~d~ {times} D~r~# + 355 [eq]#G = G~s0~ {times} S~g~ {plus} G~d~ {times} D~g~# + 356 [eq]#B = B~s0~ {times} S~b~ {plus} B~d~ {times} D~b~# 357| [eq]#A = A~s0~ {times} S~a~ {plus} A~d~ {times} D~a~# 358 359|ename:VK_BLEND_OP_SUBTRACT 360| [eq]#R = R~s0~ {times} S~r~ - R~d~ {times} D~r~# + 361 [eq]#G = G~s0~ {times} S~g~ - G~d~ {times} D~g~# + 362 [eq]#B = B~s0~ {times} S~b~ - B~d~ {times} D~b~# 363| [eq]#A = A~s0~ {times} S~a~ - A~d~ {times} D~a~# 364 365|ename:VK_BLEND_OP_REVERSE_SUBTRACT 366| [eq]#R = R~d~ {times} D~r~ - R~s0~ {times} S~r~# + 367 [eq]#G = G~d~ {times} D~g~ - G~s0~ {times} S~g~# + 368 [eq]#B = B~d~ {times} D~b~ - B~s0~ {times} S~b~# 369| [eq]#A = A~d~ {times} D~a~ - A~s0~ {times} S~a~# 370 371|ename:VK_BLEND_OP_MIN 372| [eq]#R = min(R~s0~,R~d~)# + 373 [eq]#G = min(G~s0~,G~d~)# + 374 [eq]#B = min(B~s0~,B~d~)# 375| [eq]#A = min(A~s0~,A~d~)# 376 377|ename:VK_BLEND_OP_MAX 378| [eq]#R = max(R~s0~,R~d~)# + 379 [eq]#G = max(G~s0~,G~d~)# + 380 [eq]#B = max(B~s0~,B~d~)# 381| [eq]#A = max(A~s0~,A~d~)# 382|==== 383 384In this table, the following conventions are used: 385 386 * [eq]#R~s0~, G~s0~, B~s0~# and [eq]#A~s0~# represent the first source 387 color R, G, B, and A components, respectively. 388 * [eq]#R~d~, G~d~, B~d~# and [eq]#A~d~# represent the R, G, B, and A 389 components of the destination color. 390 That is, the color currently in the corresponding color attachment for 391 this fragment/sample. 392 * [eq]#S~r~, S~g~, S~b~# and [eq]#S~a~# represent the source blend factor 393 R, G, B, and A components, respectively. 394 * [eq]#D~r~, D~g~, D~b~# and [eq]#D~a~# represent the destination blend 395 factor R, G, B, and A components, respectively. 396 397The blending operation produces a new set of values [eq]#R, G, B# and 398[eq]#A#, which are written to the framebuffer attachment. 399If blending is not enabled for this attachment, then [eq]#R, G, B# and 400[eq]#A# are assigned [eq]#R~s0~, G~s0~, B~s0~# and [eq]#A~s0~#, 401respectively. 402 403If the color attachment is fixed-point, the components of the source and 404destination values and blend factors are each clamped to [eq]#[0,1]# or 405[eq]#[-1,1]# respectively for an unsigned normalized or signed normalized 406color attachment prior to evaluating the blend operations. 407If the color attachment is floating-point, no clamping occurs. 408 409-- 410 411If the numeric format of a framebuffer attachment uses sRGB encoding, the R, 412G, and B destination color values (after conversion from fixed-point to 413floating-point) are considered to be encoded for the sRGB color space and 414hence are linearized prior to their use in blending. 415Each R, G, and B component is converted from nonlinear to linear as 416described in the "`sRGB EOTF`" section of the <<data-format,Khronos Data 417Format Specification>>. 418If the format is not sRGB, no linearization is performed. 419 420If the numeric format of a framebuffer attachment uses sRGB encoding, then 421the final R, G and B values are converted into the nonlinear sRGB 422representation before being written to the framebuffer attachment as 423described in the "`sRGB EOTF^ -1^`" section of the Khronos Data Format 424Specification. 425 426If the framebuffer color attachment numeric format is not sRGB encoded then 427the resulting [eq]#c~s~# values for R, G and B are unmodified. 428The value of A is never sRGB encoded. 429That is, the alpha component is always stored in memory as linear. 430 431If the framebuffer color attachment is ename:VK_ATTACHMENT_UNUSED, no writes 432are performed through that attachment. 433Framebuffer color attachments greater than or equal to 434sname:VkSubpassDescription::pname:colorAttachmentCount perform no writes. 435 436ifdef::VK_EXT_blend_operation_advanced[] 437include::VK_EXT_blend_operation_advanced/advanced_blend.txt[] 438endif::VK_EXT_blend_operation_advanced[] 439 440[[framebuffer-logicop]] 441== Logical Operations 442 443The application can: enable a _logical operation_ between the fragment's 444color values and the existing value in the framebuffer attachment. 445This logical operation is applied prior to updating the framebuffer 446attachment. 447Logical operations are applied only for signed and unsigned integer and 448normalized integer framebuffers. 449Logical operations are not applied to floating-point or sRGB format color 450attachments. 451 452[open,refpage='VkLogicOp',desc='Framebuffer logical operations',type='enums'] 453-- 454 455Logical operations are controlled by the pname:logicOpEnable and 456pname:logicOp members of slink:VkPipelineColorBlendStateCreateInfo. 457If pname:logicOpEnable is ename:VK_TRUE, then a logical operation selected 458by pname:logicOp is applied between each color attachment and the fragment's 459corresponding output value, and blending of all attachments is treated as if 460it were disabled. 461Any attachments using color formats for which logical operations are not 462supported simply pass through the color values unmodified. 463The logical operation is applied independently for each of the red, green, 464blue, and alpha components. 465The pname:logicOp is selected from the following operations: 466 467include::../api/enums/VkLogicOp.txt[] 468 469<<< 470 471The logical operations supported by Vulkan are summarized in the following 472table in which 473 474 * [eq]#{lnot}# is bitwise invert, 475 * [eq]#{land}# is bitwise and, 476 * [eq]#{lor}# is bitwise or, 477 * [eq]#{oplus}# is bitwise exclusive or, 478 * [eq]#s# is the fragment's [eq]#R~s0~, G~s0~, B~s0~# or [eq]#A~s0~# 479 component value for the fragment output corresponding to the color 480 attachment being updated, and 481 * [eq]#d# is the color attachment's [eq]#R, G, B# or [eq]#A# component 482 value: 483 484.Logical Operations 485[width="75%",options="header",align="center"] 486|==== 487|Mode | Operation 488|ename:VK_LOGIC_OP_CLEAR | [eq]#0# 489|ename:VK_LOGIC_OP_AND | [eq]#s {land} d# 490|ename:VK_LOGIC_OP_AND_REVERSE | [eq]#s {land} {lnot} d# 491|ename:VK_LOGIC_OP_COPY | [eq]#s# 492|ename:VK_LOGIC_OP_AND_INVERTED | [eq]#{lnot} s {land} d# 493|ename:VK_LOGIC_OP_NO_OP | [eq]#d# 494|ename:VK_LOGIC_OP_XOR | [eq]#s {oplus} d# 495|ename:VK_LOGIC_OP_OR | [eq]#s {lor} d# 496|ename:VK_LOGIC_OP_NOR | [eq]#{lnot} (s {lor} d)# 497|ename:VK_LOGIC_OP_EQUIVALENT | [eq]#{lnot} (s {oplus} d)# 498|ename:VK_LOGIC_OP_INVERT | [eq]#{lnot} d# 499|ename:VK_LOGIC_OP_OR_REVERSE | [eq]#s {lor} {lnot} d# 500|ename:VK_LOGIC_OP_COPY_INVERTED | [eq]#{lnot} s# 501|ename:VK_LOGIC_OP_OR_INVERTED | [eq]#{lnot} s {lor} d# 502|ename:VK_LOGIC_OP_NAND | [eq]#{lnot} (s {land} d)# 503|ename:VK_LOGIC_OP_SET | all 1s 504|==== 505 506The result of the logical operation is then written to the color attachment 507as controlled by the component write mask, described in 508<<framebuffer-blendoperations,Blend Operations>>. 509 510-- 511 512 513[[framebuffer-color-write-mask]] 514== Color Write Mask 515 516[open,refpage='VkColorComponentFlagBits',desc='Bitmask controlling which components are written to the framebuffer',type='enums'] 517-- 518 519Bits which can: be set in 520slink:VkPipelineColorBlendAttachmentState::pname:colorWriteMask to determine 521whether the final color values [eq]#R, G, B# and [eq]#A# are written to the 522framebuffer attachment are: 523 524include::../api/enums/VkColorComponentFlagBits.txt[] 525 526 * ename:VK_COLOR_COMPONENT_R_BIT specifies that the [eq]#R# value is 527 written to the color attachment for the appropriate sample. 528 Otherwise, the value in memory is unmodified. 529 * ename:VK_COLOR_COMPONENT_G_BIT specifies that the [eq]#G# value is 530 written to the color attachment for the appropriate sample. 531 Otherwise, the value in memory is unmodified. 532 * ename:VK_COLOR_COMPONENT_B_BIT specifies that the [eq]#B# value is 533 written to the color attachment for the appropriate sample. 534 Otherwise, the value in memory is unmodified. 535 * ename:VK_COLOR_COMPONENT_A_BIT specifies that the [eq]#A# value is 536 written to the color attachment for the appropriate sample. 537 Otherwise, the value in memory is unmodified. 538 539The color write mask operation is applied regardless of whether blending is 540enabled. 541 542-- 543 544[open,refpage='VkColorComponentFlags',desc='Bitmask of VkColorComponentFlagBits',type='enums'] 545-- 546include::../api/flags/VkColorComponentFlags.txt[] 547 548sname:VkColorComponentFlags is a bitmask type for setting a mask of zero or 549more slink:VkColorComponentFlagBits. 550-- 551