KhronosGroup / KhronosGroup/OpenCL-Docs

Is the SPIR-V ImageBuffer capability required?

Open
#1,615 2 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.