KhronosGroup / KhronosGroup/OpenCL-Docs
Is the SPIR-V ImageBuffer capability required?
- Dominant language
- Python
- Stars
- 420
- Forks
- 131
- Avg merge
- 5d 13h
- Merged PRs (30d)
- 11
Description
The SPIR-V environment spec currently requires support for the **ImageBuffer** capability when images are supported.
https://registry.khronos.org/OpenCL/specs/unified/html/OpenCL_Env.html#required-capabilities-1.0
> If the OpenCL environment supports the **ImageBasic** capability, then the following capabilities must also be supported:
> * ...
> * **ImageBuffer**
> * ...
In the SPIR-V specification, the description of the **ImageBuffer** capability is:
https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#Capability
> **ImageBuffer**
> Uses the **Buffer** [Dim](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#Dim) with an [**OpTypeImage**](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#OpTypeImage) having _Sampled_ == 2.
But then, back in the SPIR-V environment spec, we have the validation rule:
https://registry.khronos.org/OpenCL/specs/unified/html/OpenCL_Env.html#validation-rules
> For all **OpTypeImage** type-declaration instructions:
> * ...
> * _Sampled_ must be 0, indicating that the image usage will be known at run time, not at compile time.
So, it seems like there is an internal inconsistency, and we cannot require both the **ImageBuffer** capability to be supported and require _Samples_ to be zero.
Since [**OpImageWrite**](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#OpImageWrite) supports writing to images with _Sampled_ equal to zero or 2, I don't think there is any reason for OpenCL to require _Sampled_ equal to 2, which means there is no need to support the **ImageBuffer** capability, either.
Note: If we fix this in the specification, we also need to update the SPIR-V queries CTS test, which is checking for the presence of the **ImageBuffer** capability when images are supported. Updating the spec and the test will not cause shipping implementations to become non-conformant, since it is not an error to advertise more capabilities than those required by the specification.
Contributor guide
Research direction
Compare the linked OpenCL environment capability requirements and validation rules with the SPIR-V ImageBuffer definition to confirm the inconsistency. Then inspect the SPIR-V queries CTS test mentioned in the issue; done means the specification and test agree on the resolved ImageBuffer requirement without making existing implementations non-conformant.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation, testing
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100