SPIR-V | a simple SPIR-V parser | Parser library

It is 3 am in the morning over here, I should just go to sleep.
Chances anyone end up having the same problem are small, but I'd still rather answer it myself than delete it:
I simply had to add a SpecializationConstant to set the size of the sampler2D array, now it works without requiring any extension.
Good night

This is a matter of calling conventions. Or rather, the lack of calling conventions in SPIR-V.

Higher-level languages like GLSL and HLSL have calling conventions. They explain what it means for a function to take an input parameter and how that relates to the argument being given to it.

SPIR-V doesn't have calling conventions in that sense. Or more to the point, you have to construct the calling conventions you want using SPIR-V.

Parameters in HLSL are conceptually always passed by copy. If the parameter is an input parameter, then the copy is initialized with the given argument. If the parameter is an output parameter, the data from the function is copied into the argument after calling the function.

The HLSL compiler must implement this in SPIR-V. So if a function takes a struct input parameter, that function's input parameter must be new storage from any existing object. When a caller tries to call this function, it must create storage for that parameter. That storage will use the Function storage qualifier, so the parameter also uses that qualifier.

SPIR-V requires that pointer types specify the storage qualifier of the objects they point to. This is important, as how the compiler goes about generating the GPU assembly which accesses the object can be different (perhaps drastically). As such, a function cannot accept a pointer that points to different storage classes; the function has to pick one.

So if your SPIR-V adjustment system sees a function call whose source data comes from something you need to adjust, then you have two options:

1. Create a new function which is a copy of the old one, except that it takes a Private pointer.

2. Follow the calling convention by creating Function-local storage and copying from your Private data into it prior to calling the function (and copying back out if it is an output parameter). There's probably code to do that sitting there already, so you probably only need to change where it copies from/to.

I am not sure I understand your problem correctly, but if you want your .vert.spv copied to another folder use File.Copy()

You also need to enable the VK_KHR_shader_non_semantic_info device extension in your application code when you create the device.

LunarG has also recently published a white paper about debugPrintfEXT.

To store in a rgba8uint, you need to use the type vec4. See here for the corresponding type for each texture storage. If that's not working, you may have a different problem. (Are you passing in 10. etc to the vec4? It should be 10u. Wgsl is very strict about types.)

Upon closer inspection I noticed that normally all the generated SPIR-V files for my shaders take about 10-30KB. However, this one shader takes 178KB.

With help of spirv-dis I looked inside the generated assembly and noticed that vast majority of the op-codes was OpConstant. It was because I had structs that looked like

You have to enable the feature at device creation.

You can check for support of the feature by calling vkGetPhysicalDeviceFeatures2 and following the pNext chain through to a VkPhysicalDeviceVulkan12Features, and checking that shaderSampledImageArrayNonUniformIndexing member is to VK_TRUE.

After that when creating the device with vkCreateDevice, inside the pCreateInfo structure, in the pNext chain you have to have a VkPhysicalDeviceVulkan12Features with shaderSampledImageArrayNonUniformIndexing set to VK_TRUE.

If you go here

https://vulkan.lunarg.com/doc/view/1.2.182.0/linux/1.2-extensions/vkspec.html#spirvenv-capabilities

you can scroll down to the desired extension. In this case it's

While Vulkan-flavored GLSL requires that specialization constants are scalars, SPIR-V itself is not so restrictive. You can declare a specialization constant array, just as you can declare a non-specialized constant array. The latter effectively becomes the former upon specialization constants being provided. The interface for specializing constants in Vulkan acknowledges the possibility that different constants being specialized have different sizes, so an array of them would be valid from an API perspective.

But so long as you are stuck with GLSL, you have to live within its limitations. At least, as far as SPIR-V generation is concerned.

However, if you're willing to do some surgery on the SPIR-V after generating it, you can construct what you need. Given the name of the array in question, you can track down the OpName that matches that array name. Once you find it, you can find the ResultID (every SPIR-V opcode has one) that the OpName opcode specifies. That opcode should be an OpConstantComposite.

All you need to do is turn this OpConstantComposite opcode into OpSpecConstantComposite. The two codes use the same parameters and so forth, so you're just swapping the opcode out for the other one.