Validation Layer warning for geometry shaders with the VK_NV_geometry_shader_passthrough extension enabled

[karl-lunarg]

Issue by neXyon (MIGRATED)
Wednesday May 09, 2018 at 10:00 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2661

---

I get the warning

Object: VK_NULL_HANDLE (Type = 0) | SPIR-V module not valid: Invalid decoration operand: 5250

during the call to vkCreateShaderModule when I use a geometry shader with

#extension GL_NV_geometry_shader_passthrough : enable

and I have the extension VK_NV_geometry_shader_passthrough enabled. The compiled shader then contains the PassthroughNV (5250) decoration in accordance with https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf which is seen as invalid.

Everything works fine, but the warning shouldn't be there, since I do everything according to the specification.

I'm not sure if I should report this here or at https://github.com/KhronosGroup/SPIRV-Tools since the spvValidate function from there is producing the actual error message. Let me know if I should rather open an issue at SPIRV-Tools.

[karl-lunarg]

Comment by tobine (MIGRATED)
Wednesday May 09, 2018 at 13:21 GMT

---

Ping @chrisforbes, should this go to SPIRV-Tool repo?

[karl-lunarg]

Comment by chrisforbes (MIGRATED)
Wednesday May 09, 2018 at 16:44 GMT

---

Yes, this needs a bug filed in SPIRV-Tools.. we'll likely have some tidying up in LVL to do after SPIRV-Tools fixes their side though, so keep this bug open also.

[karl-lunarg]

Comment by neXyon (MIGRATED)
Wednesday May 09, 2018 at 17:01 GMT

---

Ok, I opened an issue there as well: KhronosGroup/SPIRV-Tools#1553

[karl-lunarg]

Comment by neXyon (MIGRATED)
Friday May 11, 2018 at 07:02 GMT

---

The issue in SPIRV-Tools has been fixed already.

[neXyon]

Hello! Is there any progress on this? I noticed that with a recent release the code of the error changed from 5 to -1.

[mark-lunarg]

@neXyon, does this issue still manifest? We didn't notice any related validation errors in our CTS test logs...

[neXyon]

Looks, like it's fixed now! Thanks. Didn't run into the issue because we have dropped usage of this extension, but I just checked an old branch and looks like the issue is gone.

[mark-lunarg]

Sweet!