Feature Request: disable removing of blend state info on pipeline create

[TiemoJung]

Hi,

the situation is as follows.

We create a new graphics pipeline, the fragment shader writes to one or more color outputs. The used pass marks all color attachments as unused via VK_ATTACHMENT_UNUSED. Leaving only depth/stencil to be used.

We always provide the blend state info, even in this case. This works fine, as expected. But if we enable in this case the debug layer, it filters in this case the blend state info of the pipeline create struct - setting the pointer to null.

This causes a crash inside some drivers (we already contacted the vendor).

Is there a possibility to disable this at runtime, currently we avoid this by using a modified version of the debug layer. But this is not a great solution to avoid this.

[tobine]

This is an interesting issue. The code in question is here

We do blast any existing pColorBlendState pointer if rasterization is disabled or if there are no color attachments. The spec justification for this is:

pColorBlendState is a pointer to an instance of the VkPipelineColorBlendStateCreateInfo structure, and is ignored if the pipeline has rasterization disabled or if the subpass of the render pass the pipeline is created against does not use any color attachments.

In general we don't overwrite any input state in validation, but I believe the PSO is an exception b/c there were a number of cases of bad pointers (uninitialized data) crashing validation. I'm wary to change this in default layers as I fear it would cause more crashes than it would prevent.

Anyone else have thoughts? Agree/disagree?

I put a quick hack fix on a branch for reference.

[mark-lunarg]

@tobine, I agree that changing the default layers is not optimal. Perhaps it's sufficient for @TiemoJung to use the branch you created until the driver issues are ironed out? This check was added in mid-December so another option would be to go back to the 1.0.66 version of the layers.

[tobine]

I've looked at this further after having a few work-around attempts fail various tests. The actual issue is here in the CreateGraphicsPipelines() function of unique_objects. The issue is that we use the safe_struct wrapper as the local struct to store the unwrapped handles. In doing so, any ignored ptrs are currently set to NULL such as in the init code I referenced in my first update on this issue.

The main issue is that the ignored ptrs may be actual bad data, in which case we can't initialize a safe_struct for them. I tried a number of simple workaround but they all generally break if the ptr or its attachmentCount data or ptr are bad.

I think the best solution here would be to stop using the safe_VkGraphicsPipelineCreateInfo wrapper in this unique_objects case. I haven't looked at everything that entails, but I believe it's reasonable.

Any other thoughts? I'm now of the opinion that it makes sense to do something here as validation shouldn't be blasting values like that. It's just not a high priority for me to fix this so not sure if/when I would get around to it.

[polarina]

@tobine have you considered fabricating our own VkPipelineColorBlendStateCreateInfo, ignoring whatever the applications sends us, and pass that down to the driver when rasterization is disabled?

[mark-lunarg]

This still feels like the validation layers are getting changed to accommodate a driver bug.

[tobine]

After further thought, I realized that since the issue only appears with the unique_objects layer, the reasonable workaround is to just run without the unique_object layer.

@TiemoJung are you running with "VK_LAYER_LUNARG_standard_validation" for your instance_layers? Can you instead run with the following in this EXACT order:

const char *instance_layers[] = {
    "VK_LAYER_GOOGLE_threading",
    "VK_LAYER_LUNARG_parameter_validation",
    "VK_LAYER_LUNARG_object_tracker",
    "VK_LAYER_LUNARG_core_validation"
};

Then point to instance_layers in your VkInstanceCreateInfo.ppEnabledLayerNames. This is the current validation layer stack but excludes VK_LAYER_GOOGLE_unique_objects layer at the bottom.

You can see example code of using an explicit validation layer stack on this page, but note that the example there includes the unique_objects layer, which you will want to exclude.

[TiemoJung]

Ok, that will do it too, thanks.