incorrect execution for simple reduction sample

[FROL256]

incorrect execution for simple reduction sample

[rjodinchr]

Is there a reason not to use clvk?
If you want to continue with your own vulkan code to iteract with code generated by clspv, I would advise to start by parsing the non semantic reflections that are inside the SPIR-V code.
When you disassemble z_generated.cl.spv with spirv-dis, you will find that information at the end (note that you can get that information using spirv-tools without having to disassemble):

        %176 = OpExtInst %void %172 Kernel %22 %173 %uint_6 %uint_0 %174
        %177 = OpExtInst %void %172 PropertyRequiredWorkgroupSize %176 %uint_1 %uint_1 %uint_1
        %179 = OpExtInst %void %172 ArgumentInfo %178
        %180 = OpExtInst %void %172 ArgumentStorageBuffer %176 %uint_1 %uint_0 %uint_0 %179
        %183 = OpExtInst %void %172 Kernel %37 %181 %uint_6 %uint_0 %182
        %184 = OpExtInst %void %172 PropertyRequiredWorkgroupSize %183 %uint_256 %uint_1 %uint_1
        %186 = OpExtInst %void %172 ArgumentInfo %185
        %187 = OpExtInst %void %172 ArgumentStorageBuffer %183 %uint_0 %uint_0 %uint_1 %186
        %189 = OpExtInst %void %172 ArgumentInfo %188
        %190 = OpExtInst %void %172 ArgumentStorageBuffer %183 %uint_1 %uint_0 %uint_0 %189
        %192 = OpExtInst %void %172 ArgumentInfo %191
        %193 = OpExtInst %void %172 ArgumentPodPushConstant %183 %uint_2 %uint_0 %uint_4 %192
        %195 = OpExtInst %void %172 ArgumentInfo %194
        %197 = OpExtInst %void %172 ArgumentPodPushConstant %183 %uint_3 %uint_4 %uint_4 %195
        %199 = OpExtInst %void %172 ArgumentInfo %198
        %200 = OpExtInst %void %172 ArgumentPodPushConstant %183 %uint_4 %uint_8 %uint_4 %199
        %202 = OpExtInst %void %172 ArgumentInfo %201
        %205 = OpExtInst %void %172 ArgumentPodPushConstant %183 %uint_5 %uint_12 %uint_4 %202

[FROL256]

Unfortunately yes, i need Vulkan itself. In general i need graphics features like ray tracing, dynamic descriptor indexing, BC compression and other. Therefore some kernels are unfortunately must be created with GLSL and bind with Vulkan directly. So, what basically i want from clspv is to have some kernels in OpenCL C and others in GLSL anyway.

Thank you very much for the advice. Could you please clarify what I need to pay attention to this disasm? I'm not very familiar with SPIR-V understanding )

[rjodinchr]

You can find more information about each OpExtInst in the spirv-headers.

Basically, for the ArgumentPodPushConstant you want to make sure that you are using the correct offset. And for the ArgumentStorageBuffer you want to make sure you are using the same descriptorset and binding.

[rjodinchr]

if you look at those 2 lines:

%187       = OpExtInst %void %172 ArgumentStorageBuffer  %183      %uint_0   %uint_0 %uint_1   %186
%190       = OpExtInst %void %172 ArgumentStorageBuffer  %183      %uint_1   %uint_0 %uint_0   %189
<spirv-id> = OpExtInst %void %172 ArgumentStorageBuffer <decl_id> <ordinal> <ds>    <binding> <arginfo>

You can see that the first argument of the kernel (ordinal 0) is set to the descriptorset 0 with binding 1, while the second arg (ordinal 1) is set to descriptor 0 with binding 0.
It can feel weird to have exchanged those 2, I don't know why clspv did that, there might be multiple reasons. But in the end, you need to stick to that mapping.

[FROL256]

Thank you very much, understood!