Feature Request: Ability to access default values for parameters in a constant buffer (ubo)

[GregSlazinski]

Please check this post: https://github.com/KhronosGroup/SPIRV-Cross/issues/1094 I use Microsoft directx shader compiler to generate spirv code from hlsl and process it using spirv-cross library. Inside hlsl code I define a constant buffer:

cbuffer XX 
{
   float x;
   float2 param[2]={float2(0,1), float2(2,3)};
}

I would like to be able to access the default values for 'param' This can be done in d3d reflection api (when compiling to dxil byte code instead of spirv), but I haven't seen an option to do it in spirv. Thank you very much

[johnkslang]

Yes, glslang currently emits:

WARNING: t.vert:4: 'typedef' : struct-member initializers ignored

This is because the shader does not really initialize these values; the driver does. It is information that does not belong in the shader other than as syntactic sugar for a driver operation.

At some point, the initializers need to become side-band data, and that has not been done yet for the glslang path.

Do you know for other tool chains if it always stays in the shader, or when it becomes part of some other payload?

[johnkslang]

I just realized this is the SPIRV-Header project, not glslang.

Can you submit this against the tool you are having trouble with?

[GregSlazinski]

I was redirected here by @HansKristian-Work from https://github.com/KhronosGroup/SPIRV-Cross as I was told this is the place for SPIR-V spec related issues. He said that this cannot be expressed in SPIR-V. So I think this feature should be added to SPIR-V spec?

[johnkslang]

Ah, you are asking that SPIR-V start carrying this information, and that client APIs properly handle it.

[HansKristian-Work]

That's how I understood it, SPIR-V cannot represent this meta-data so I redirected the issue here. Perhaps adding support for OpDecorateMemberID with a constant would help here.

[johnkslang]

I can see it for non-buffer uniforms, and SPIR-V does say already that is up to the client, and it can be handled naturally just as an initializer.

That also makes sense for a structure.

But a SPIR-V buffer (Vulkan SSBO or UBO) seems odd to do this for. And, Vulkan only allows buffers.

What is the full specification of what should happen? That the driver strip this from the SPIR-V and partially overwrite application buffers with it? When?

[HansKristian-Work]

Right, it does get annoying since drivers would have to understand that SPIR-V, and that's another extension which seems rather overkill. Unfortunately this kind of falls between debug info and decorations in scope I think, and there is no standard way for shaders to add external meta-data which drivers know how to ignore, and for tools not to strip away.