[Impeller] Do not terminate on performance related validation failures #36776
Conversation
Example: ``` Warning: Validation Performance Warning: [ UNASSIGNED-CoreValidation-Shader-OutputNotConsumed ] Object 0: handle = 0x980b0000000002e, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x609a13b | vertex shader writes to output location 1.0 which is not consumed by fragment shader. Enable VK_KHR_maintenance4 device extension to allow relaxed interface matching between input and output vectors. ``` In cases like these where SPIRV-Cross optimizes away unused uniforms in fragment shaders, there isn't an easy way to detect and not drop these. Current constraints mean that `VK_KHR_maintenance4` can not be guaranteed to be available. So we log and continue.
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!). If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
| FML_DCHECK(false) | ||
| << vk::to_string(vk::DebugUtilsMessageSeverityFlagBitsEXT{severity}) | ||
| << ": " << data->pMessage; | ||
| if (type == VK_DEBUG_UTILS_MESSAGE_TYPE_PERFORMANCE_BIT_EXT) { |
There was a problem hiding this comment.
This is a bitmask right?
| if (type == VK_DEBUG_UTILS_MESSAGE_TYPE_PERFORMANCE_BIT_EXT) { | |
| if (type & VK_DEBUG_UTILS_MESSAGE_TYPE_PERFORMANCE_BIT_EXT == VK_DEBUG_UTILS_MESSAGE_TYPE_PERFORMANCE_BIT_EXT) { |
There was a problem hiding this comment.
Or is it that we still wnat to terminate if anything else is in the bitmask?
There was a problem hiding this comment.
Yes, we will want to terminate if it isn't an explicit performance only validation failure.
iskakaushik
added
the
autosubmit
2 participants
Example:
In cases like these where SPIRV-Cross optimizes away unused uniforms in fragment shaders, there isn't an easy way to detect and not drop these. Current constraints mean that
VK_KHR_maintenance4can not be guaranteed to be available. So we log and continue.