[spirv] support vk::ext_execution_mode_id(..)

[jaebaek]

As a part of HLSL version of GL_EXT_spirv_intrinsics, this commit adds
vk::ext_execution_mode_id(..) intrinsic function. In addition, it allows users
to enable capabilites and extensions via vk::ext_execution_mode[_id](..)
using [[vk::ext_capability(..)]] and [[vk::ext_extension(..)]].

Related to #3919

[jaebaek]

@jiaolu Hi, Jiao Lu. This commit will add vk::ext_execution_mode_id(..). Could you please give me some feedback if you have any concerns?

[AppVeyorBot]

✅ Build DirectXShaderCompiler 1.0.1069 completed (commit c99148a63e by @jaebaek)

[AppVeyorBot]

✅ Build DirectXShaderCompiler 1.0.1071 completed (commit 3413097bea by @jaebaek)

[jiaolu]

the vk::ext_execution_mode function call with extension and capability looks a little bit heavy

i think we might introduce new intrinsic functions directly.
vk::ext_capability(5055);
vk::ext_extension("SPV_KHR_shader_clock")

or
put these vk::attributes before entry functions.

[[vk::ext_capability(5055)]]
[[vk::ext_extension("SPV_KHR_shader_clock")]]
[[vk::ext_decorate(11, 5014)]]
int main() : SV_Target0 {
}

[jaebaek]

Actually I also thought we have to add separate functions for capabilities and extensions.

However, in our email discussion (between you and me and Tobias Hector) a few months ago, Tobias Hector said

users don’t have to think about which extensions/capabilities they need to use when pulling in a header, and so they could pull in headers without any worry that they’re adding unnecessary capabilities to their code. So if you wanted to use e.g. clockRealtime2x32EXT, you’d just include the header and call clockRealtime2x32EXT. If you include the header and don’t call it? No worries – no extra capabilities/extensions specified.

This is the motivation to add capabilities and extensions as attributes in the initial GLSL version of GL_EXT_spirv_intrinsics design.

For example, I think Tobias Hector is worried about the following case:

// Separate functions for capabilities and extensions:
#ifdef ENABLE_DEMOTE_TO_HELPER
vk::ext_capability(/* DemoteToHelperInvocationEXT */ 5379);
vk::ext_extension("SPV_EXT_demote_to_helper_invocation");
#endif

#ifdef OPTION1
[[vk::ext_instruction(/*OpDemoteToHelperInvocationEXT*/ 5380)]]
void DemoteToHelperInvocation();
#endif

#ifdef OPTION2
[[vk::ext_instruction(/*OpIsHelperInvocationEXT*/ 5381)]]
bool IsHelperInvocation();
#endif

// With attributes
#ifdef OPTION1
[[vk::ext_capability(/* DemoteToHelperInvocationEXT */ 5379)]]
[[vk::ext_extension("SPV_EXT_demote_to_helper_invocation")]]
[[vk::ext_instruction(/*OpDemoteToHelperInvocationEXT*/ 5380)]]
void DemoteToHelperInvocation();
#endif

#ifdef OPTION2
[[vk::ext_capability(/* DemoteToHelperInvocationEXT */ 5379)]]
[[vk::ext_extension("SPV_EXT_demote_to_helper_invocation")]]
[[vk::ext_instruction(/*OpIsHelperInvocationEXT*/ 5381)]]
bool IsHelperInvocation();
#endif

When the code size becomes big e.g., more than 3000 lines and many preprocessor based options and header files, users can miss enabling capabilites and extensions if we separate them from vk::ext_instruction or vk::ext_execution_mode or vk::ext_type_def.

I agree with Tobias Hector's opinion. Just I think it would be unlikely that users use this feature for actual game shaders that has more than 1000 lines. I guess it would be mainly used by hardware vendors to test new specs.
However, since we can prevent users from making mistakes using some language design, I think this is a reasonable direction to go.

[jiaolu]

Actually I also thought we have to add separate functions for capabilities and extensions.

However, in our email discussion (between you and me and Tobias Hector) a few months ago, Tobias Hector said

users don’t have to think about which extensions/capabilities they need to use when pulling in a header, and so they could pull in headers without any worry that they’re adding unnecessary capabilities to their code. So if you wanted to use e.g. clockRealtime2x32EXT, you’d just include the header and call clockRealtime2x32EXT. If you include the header and don’t call it? No worries – no extra capabilities/extensions specified.

This is the motivation to add capabilities and extensions as attributes in the initial GLSL version of GL_EXT_spirv_intrinsics design.

For example, I think Tobias Hector is worried about the following case:

// Separate functions for capabilities and extensions:
#ifdef ENABLE_DEMOTE_TO_HELPER
vk::ext_capability(/* DemoteToHelperInvocationEXT */ 5379);
vk::ext_extension("SPV_EXT_demote_to_helper_invocation");
#endif

#ifdef OPTION1
[[vk::ext_instruction(/*OpDemoteToHelperInvocationEXT*/ 5380)]]
void DemoteToHelperInvocation();
#endif

#ifdef OPTION2
[[vk::ext_instruction(/*OpIsHelperInvocationEXT*/ 5381)]]
bool IsHelperInvocation();
#endif

// With attributes
#ifdef OPTION1
[[vk::ext_capability(/* DemoteToHelperInvocationEXT */ 5379)]]
[[vk::ext_extension("SPV_EXT_demote_to_helper_invocation")]]
[[vk::ext_instruction(/*OpDemoteToHelperInvocationEXT*/ 5380)]]
void DemoteToHelperInvocation();
#endif

#ifdef OPTION2
[[vk::ext_capability(/* DemoteToHelperInvocationEXT */ 5379)]]
[[vk::ext_extension("SPV_EXT_demote_to_helper_invocation")]]
[[vk::ext_instruction(/*OpIsHelperInvocationEXT*/ 5381)]]
bool IsHelperInvocation();
#endif

When the code size becomes big e.g., more than 3000 lines and many preprocessor based options and header files, users can miss enabling capabilites and extensions if we separate them from vk::ext_instruction or vk::ext_execution_mode or vk::ext_type_def.

I agree with Tobias Hector's opinion. Just I think it would be unlikely that users use this feature for actual game shaders that has more than 1000 lines. I guess it would be mainly used by hardware vendors to test new specs. However, since we can prevent users from making mistakes using some language design, I think this is a reasonable direction to go.

thanks, it makes sense.

[AppVeyorBot]

✅ Build DirectXShaderCompiler 1.0.1074 completed (commit a416ed3221 by @jaebaek)

[sudonatalie]

LGTM!