[SPIR-V] Prevent spriv from generating with gl_BaseInstance

[maluoi]

I have a tool that, among other things, takes HLSL -> SPIR-V -> GLSL ES. GLSL ES can't handle gl_BaseInstance, but I'm also not using this functionality at all, and don't plan on taking advantage of it in the future. My HLSL does use SV_InstanceID, but no offsetting of any kind. Is there a way to prevent DXC from generating this in the SPIR-V output?

It looks like this comes from SPV_KHR_shader_draw_parameters. Looking at the spec, I think I'd be happy to just turn this extension off if I could. Is that possible?

I suppose I'll also add that I didn't have this issue when I was using the March 2020 release of DXC. (edit: apparently not quite the March release, I built from source on commit 29759a8 at the end of June)

[ehsannas]

Seems the same as #3106

[ehsannas]

SPIR-V codegen is generating gl_BaseInstance to address #2946

[ehsannas]

We might need to add a command line option for this (e.g. -fspv-support-nonzero-base-instance), and have the default behavior to assume base instance is zero.

[maluoi]

This does look like the same problem to me as well, and the proposed solution sounds like it would fix the issue on my end! :) Thanks for looking into it!

[awesomekyle]

As an alternative, or in addition to a command line switch, could the gl_InstanceIndex be exposed directly as a built in ([[vk::builtin("InstanceIndex")]])? I'm using DXC to generate Vulkan shaders for PC where I want the functionality of gl_InstanceIndex with a non-zero BaseInstance. A built-in would allow SV_InstanceID to continue to work as is, while also allowing a shader access to the built-in SPIR-V BaseInstance and InstanceIndex variables. The SPIR-V DXC documentation is currently incorrect, because it states SV_InstanceID maps to the InstanceIndex built-in, with no mention of the "correction" applied to align it with DX12 semantics.

[jaebaek]

@awesomekyle I opened a new bug for your request: #3479.
I am a little bit worried we add many vk::builtin variables or functions, but it is worth considering it.
I will get back to you after considering it a little bit more.