Invalid SPIR-V for image sampling ops and spec/model mismatch for non-sampled reads

[Seanst98]

Generated Image Sample/Fetch SPIR-V is invalid

DPC++ emits OpImageSample* (or other related sampling ops) with a result type that is not a 4-component vector, which violates SPIR-V validity rules for sampling instructions. For example, the spec for OpImageSampleExplicitLod states

Result Type must be a vector of four components of floating-point type or integer type

Compile any bindless sampled image test which uses non-4-component vector returns, such as sampling_1D.cpp and run the generated SPIR-V through the spirv validator:

> spirv-val.exe sycl_spir64.spv
error: line 156: Expected Result Type to be int or float vector type
  %call1_i_i_i = OpImageSampleExplicitLod %float %call_i_i %div_i_i Lod %float_0

This can be fixed in DPC++ pretty simply and I have a patch for this which I can post a PR for soon.

Spec/model mismatch

SPIR-V allows OpImageRead / non-sampling reads to return either a scalar or a vector of various widths. In contrast, OpenCL's built-in image read functions always return 4-component vectors. This is not necessarily invalid SPIR-V by itself, however, when targeting the OpenCL execution environment, additional constraints may demand the enforcement of OpenCL-style vector widths.

It would be helpful to clarify whether DPC++ intends to strictly follow OpenCL's image semantics in its SPIR-V lowering, or whether narrower result types are considered acceptable under the OpenCL execution environment.

Example: SPIRV-LLVM-Translator behavior under OpenCL semantics

For an example of the trade-off between strictly following the SPIR-V specification and targeting OpenCL image semantics, we can examine the behavior of the upstream SPIRV-LLVM-Translator. When provided with the SPIR-V module generated by the read_write_unsampled.cpp test using the command-line invocation:

llvm-spirv --spirv-target-env CL2.0 -r read_write_unsampled.spv -o read_write_unsampled.bc 

the resulting LLVM bitcode is malformed.

This occurs due to an implicit assumption in the SPIR-V–to–OpenCL translation that OpImageRead always returns a four-component vector. When this assumption is violated, name mangling and signature mismatches occur, resulting in function definitions being incorrectly overwritten in the generated LLVM IR.

Thanks to @AdamBrouwersHarries for pointing the above out!

Tagging @bashbaug for his opinion👋, thanks!

Environment

• OS: N/A
• Target device and vendor: N/A
• DPC++ version: clang version 21.0.0
• Dependencies version: N/A

Additional context

No response

[YuriPlyakhin]

tag @0x12CC

[bashbaug]

👋 thanks for looping me in!

DPC++ compiles for both OpenCL and Level Zero devices, but the Level Zero SPIR-V environment specification is very close to the OpenCL SPIR-V environment specification, so the short answer is: yes, the SPIR-V modules DPC++ generates should generally adhere to the rules described in the OpenCL SPIR-V environment specification.

For this specific issue, there may already be a fix in flight, see: #21345

[Naghasan]

Hi @bashbaug

SPIR-V allows OpImageRead / non-sampling reads to return either a scalar or a vector of various widths. In contrast, OpenCL's built-in image read functions always return 4-component vectors. This is not necessarily invalid SPIR-V by itself, however, when targeting the OpenCL execution environment, additional constraints may demand the enforcement of OpenCL-style vector widths.

One thing Sean also tried to point out here is the environment spec doesn't explicitly restrict types, so you have to look up the OpenCL C specs to understand this restriction. The side effect is this is not checked by spirv-val either. Is that already tracked by the OCL WG group ?

[bashbaug]

One thing Sean also tried to point out here is the environment spec doesn't explicitly restrict types [...]

Could you have a look at this section in the OpenCL SPIR-V environment spec?

https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_Env.html#_data_format_for_reading_and_writing_images

I'd love suggestions to make this better, but I think this is the type of information you are looking for?

Couple of notes:

1. We're somewhat limited in what the SPIR-V validator can (statically) check for due to OpenCL requirements for OpTypeImage, specifically that the Sampled Type must be OpTypeVoid (so there is no differentiation between, say, integer and floating-point images) and that the Image Format must be Unknown (so we don't know the image channel order / image channel data type). Of course, this is also true for say OpenCL C's image2d_t type.
2. I think we can statically check the only valid case for scalar image data by looking at the Depth parameter to OpTypeImage vs. tying this to the depth-related image channel orders. I'll raise an OpenCL-Docs issue to discuss.
3. It looks like there is a copy-paste error in the heading for Table 13 and these should be Image Channel Data Types, not Image Channel Orders - oops!. I'll get this fixed.

[bashbaug]

The table header fix described in (3) above is here: KhronosGroup/OpenCL-Docs#1531

[Seanst98]

Thanks @bashbaug! As you point out, looks like the info is already there - our mistake 👀 ! And nice spot on the Image Channel Data Types, I hadn't even noticed. I'll try and keep an eye on KhronosGroup/OpenCL-Docs#1530 but if anything comes from discussing it then please keep this thread updated 🙏.

I'll leave this issue open as pointed out in #21345 (comment), there is more work to be done on DPC++ to prevent emitting invalid SPIR-V.