-
Notifications
You must be signed in to change notification settings - Fork 864
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clip Distance always added as member decoration even if not used? #472
Comments
We had a big discussion about this internally to Khronos a while back and the decision was that it is okay to decorate with ClipDistance (and similar), but it's the actual reading and writing that needs the capability. Unless you read or wrote to clip distance, you are not really using the hardware feature, and the hardware capability is not in use, so the capability does not need to be declared, and the consumer should not care. The reasons are somewhat complex, but have to do with cross-stage linking and some other things. Should only be an error if your SPIR-V declared the capability and the target hardware doesn't have the actual feature. |
That's fine, but the debug validation layer is failing me because of it which is super annoying. Is there a way to not declare it in the SPIRV or can we get the validation removed for this? e.g. the decoration doesn't fail validation just if it's used? Even spitting out a warning message will spew so many messages as to make the debug layer useless. |
if you want things to get moving on validation then you can add an issue to https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/ (the repo with the actual validation) |
This should be fixed now, via KhronosGroup/SPIRV-Tools#365. |
Clip/cull distances are weird, the indicator that they are used is not them being declared but the fact of reading/writing them. (See KhronosGroup/glslang#472) Usually if they are not written/read the got DCEd but when XFB is used they may be forced to remain. This makes a7xx especially grumpy. Fixes on a7xx: dEQP-VK.rasterization.provoking_vertex.transform_feedback.* Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Clip/cull distances are weird, the indicator that they are used is not them being declared but the fact of reading/writing them. (See KhronosGroup/glslang#472) Usually if they are not written/read the got DCEd but when XFB is used they may be forced to remain. This makes a7xx especially grumpy. Fixes on a7xx: dEQP-VK.rasterization.provoking_vertex.transform_feedback.* Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Clip/cull distances are weird, the indicator that they are used is not them being declared but the fact of reading/writing them. (See KhronosGroup/glslang#472) Usually if they are not written/read the got DCEd but when XFB is used they may be forced to remain. This makes a7xx especially grumpy. Fixes on a7xx: dEQP-VK.rasterization.provoking_vertex.transform_feedback.* Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Clip/cull distances are weird, the indicator that they are used is not them being declared but the fact of reading/writing them. (See KhronosGroup/glslang#472) Usually if they are not written/read the got DCEd but when XFB is used they may be forced to remain. This makes a7xx especially grumpy. Fixes on a7xx: dEQP-VK.rasterization.provoking_vertex.transform_feedback.* Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Clip/cull distances are weird, the indicator that they are used is not them being declared but the fact of reading/writing them. (See KhronosGroup/glslang#472) Usually if they are not written/read the got DCEd but when XFB is used they may be forced to remain. This makes a7xx especially grumpy. Fixes on a7xx: dEQP-VK.rasterization.provoking_vertex.transform_feedback.* Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Clip/cull distances are weird, the indicator that they are used is not them being declared but the fact of reading/writing them. (See KhronosGroup/glslang#472) Usually if they are not written/read the got DCEd but when XFB is used they may be forced to remain. This makes a7xx especially grumpy. Fixes on a7xx: dEQP-VK.rasterization.provoking_vertex.transform_feedback.* Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
My test GLSL shader
Will fail creation, with this message:
SC (ERROR): object: 0x0 type: 0 location: 8648 msgCode: 5: SPIR-V module not valid: Operand 4 of MemberDecorate requires one of these capabilities: ClipDistance
Looking through the SPRIV, I see:
Which appears to be because of
code in Initialize.cpp. I guess I'm not understanding what's going on here. It looks like this feature isn't supported by the device I am trying to create on (and AMD desktop card), but I'm not actually using the decoration, SPIRV is just outputting over generalized information. Is that what's going on? What's supposed to happen for optional features like this, are there profiles?
The text was updated successfully, but these errors were encountered: