Vulkan pipeline + color attachments

3
votes

Is it possible to have a pipeline (with appropriate fragment shader) that doesn't write to all color attachments of a pass? e.g. Pass has 2xColor + 1depth attachments. Some fragment programs may write both color01+depth, while some only write color0+depth.

Just setting the colorWriteMask to none for the unused attachment isn't successful. I haven't been able to find a pipeline configuration that will pass the validation layer. it always complains that the extra attachments are not written by the fragment shader.

2
gpuvulkan
As Nicol said there is nothing in the specs that does not explicitly allows this, so this may be a false validation. Are you using recent validation layers or the ones from the SDK? And two things I'm missing: Are you using sub passes? And do you get a validation error or a warning? If you're sure that it's a false validation it's always a good idea to report an issue at at the valdation layer repo. - Sascha Willems
"doesn't pass validation" doesn't help if we don't know what the layers are reporting. Also it would be helpful to see some code of failed attempts. - ratchet freak
The Vulkan spec has been clarified; see my answer for details. Short version: yes, this is a validation layer bug. - Nicol Bolas

2 Answers

1
votes

If this is in a separate subpass then you can simply add the color attachment to the pPreserveAttachments.

The other option is to use blending to trick the fragment shader to discard the fragment shader output and use the existing color. Using ONE for dst and ZERO for src with OP_ADD blending.

1
votes

Vulkan 1.0.18 now resolves this issue. It now makes it perfectly clear that:

The input to blending or color attachment writes is undefined for components which do not correspond to a fragment shader output.

As such, setting the write mask to none should be fine, since the value itself is undefined, but it does exist. And since nothing will be written, there's no reason to consider the state invalid.

So definitely file this as a bug to the maintainers of the validation layer in question.

Well, this poses a problem.

On the one hand, there's no reason why that shouldn't work. Whatever the value is, you're masking it off, so it is irrelevant.

On the other hand... the Vulkan specification says nothing about what happens when your FS doesn't write to an output. It doesn't say if it's legal or illegal. It doesn't say if that output is merely undefined or if the entire pipeline yields undefined behavior.

So either the validation layer is wrong or what you're trying to do is not intended to be allowed. But until the Vulkan specification clears this up, there's no way to be sure which.