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