Is there any solution to generate SPIR-V code with Kernel capability?

[YangQun1]

Hi,

I'm trying to leverage the existing SPIR-V codegen path to generate SPIR-V code with Kernel capability (Not the Shader capability). Because some backend driver APIs requires that the entry_points' execution model in SPIR-V module must be ExecutionModel::Kernel, and in SPIRV Dialect, only the Kernel capability will be mapped to Kernel execution model.

But when I trying to change the capability to Kernel, I got an error: failed to legalize operation 'hal.interface.binding.subspan'. After some investigation, I found that we have to use the SPV_KHR_storage_buffer_storage_class extension, even we use Shader capability.

So, may I ask why the hal.interface.binding.subspan legalization relies on the SPV_KHR_storage_buffer_storage_class extension? And is there any simple solution to generate SPIR-V code with Kernel capability?

Thanks

[antiagainst]

SPIR-V is a common binary intermediate language for multiple Khoronos APIs. Shader capability tree is for targeting Vulkan/OpenGL, while Kernel capability tree is for targeting OpenCL. They are quite different so it's not as simple as "just switching" the target environment. Generating GPU program with Kernel capabilities is just part of the story; you'd need host OpenCL API calls to dispatch those generated GPU programs to run them on GPUs supporting OpenCL.

SPIR-V dialect in MLIR repo support whatever SPIR-V spec means to accommodate. So it is certainly possible to generate GPU program using Kernel capabilities, as long as you give the CodeGen flow a proper spv.target_env, given that the SPIR-V conversion flow solely relies on that to decided whether it can generate certain SPIR-V ops requiring certain capabilities. Actually Intel is pushing on that direction to support their oneAPI / L0 effort. So it's doable. Though in IREE, we don't support OpenCL. IREE only supports targeting Vulkan for going down the SPIR-V CodeGen path; the runtime-kernel API are all set up like that. That's why you see the error.

SPV_KHR_storage_buffer_storage_class is a pretty safe extension to assume for Vulkan-favored SPIR-V. It's like a "bugfix" to the initial v1 spec and widely available. So we require it in IREE. It's used to allow certain SPIR-V decorations on interface buffers. So that's why you see hal.interface.binding.subspan triggers it, because hal.interface.binding.subspan is meant to model runtime buffer views in IREE.

Let me know whether the above is clear. Happy to explain more. :)

[YangQun1]

Many thanks! You kindly reply is very helpful for me to understand IREE and the SPIR-V codegen path. And the discussions in this link also give me many useful information. I'm going to study these things first, and will put my feedback here later, thanks again :)