I’m still learning Vulkan through Intel Vulkan Tutorial. There’s this one part that I don’t understand. In part 3, they added the colorBlendStateCreateInfo to accommodate the information required by the graphics pipeline creation. According to the tutorial, it can contain attachments that tells the graphics card how to and where to draw (please correct me if I’m wrong).
Out of my curiosity, I tried to remove this part on the graphics pipeline, so I did not give the graphicsPipelineCreateInfo any colorBlendStateCreateInfo (a nullptr). The program still run just fine, and the validation layer also did not tell if such info is missing. However, visually it does not show any triangle, so surely something is wrong without the colorBlendStateCreateInfo.
What I want to know is, is there any default operations run by the graphics card if I don’t provide such information? or is it a bug from validation layer that not passing colorBlendStateCreateInfo is fine?
Just wondering that some other state create infos throw errors when I removed them, but why this one does not.
Having NULL pipelineColorBlendState in pipeline equals to having rasterization disabled or having no color attachments at all.
Read the spec (it’s very readable, like a reference pages – actually reference pages are copied directly from it). You can disable “real blending” inside the blending struct with member blendEnable.
Actually assuming all else is same, what you do is invalid and layer should have reported it.
[QUOTE=krOoze;40592]Having NULL pipelineColorBlendState in pipeline equals to having rasterization disabled or having no color attachments at all.
Read the spec (it’s very readable, like a reference pages – actually reference pages are copied directly from it). You can disable “real blending” inside the blending struct with member blendEnable.
Actually assuming all else is same, what you do is invalid and layer should have reported it.[/QUOTE]
Oh right, the spec explained it… my bad. I guess I’ll read this more before jumping to other conclusions. Thanks for the reference and the explanation!
I just tested this out of curiosity and it seems that the validation layers are missing this, so I felt the urge to open up an issue on this
@Alectora: As krOoze noted, the spec is a great document to find out about these things. It’s constantly being worked on and great source of information on the API. And if spot something in the specs that the validation does not catch, feel free to open up an issue at the official github repository for the validation layers.
As a small note: The validation layers are constantly being worked on, so it’s a good idea to build them from the current sources instead of using the dated ones from the last SDK.
[QUOTE=Sascha Willems;40599]I just tested this out of curiosity and it seems that the validation layers are missing this, so I felt the urge to open up an issue on this
@Alectora: As krOoze noted, the spec is a great document to find out about these things. It’s constantly being worked on and great source of information on the API. And if spot something in the specs that the validation does not catch, feel free to open up an issue at the official github repository for the validation layers.
As a small note: The validation layers are constantly being worked on, so it’s a good idea to build them from the current sources instead of using the dated ones from the last SDK.[/QUOTE]
Yeah I’m directly referencing to the spec from now. Also thanks for the info and for forwarding the issue Sascha.
