KhronosGroup / KhronosGroup/OpenCL-Docs

Inconsistent generic address space behavior for OpenCL 2.0

Open
#753 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
420
Forks
131
Avg merge
5d 13h
Merged PRs (30d)
11

Description

It seems that generic address space with built-in functions has changed for OpenCL 2.0 in the unified spec.

- In **OpenCL C 2.0 document** we had the follwowing for _vloadn_ overloads:

https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenCL_C.html#vector-data-load-and-store-functions

```
gentypen vloadn(size_t offset, const gentype *p)
gentypen vloadn(size_t offset, const __constant gentype *p)

```

- In **OpenCL C 3.0 unified document** we have the following for _vloadn_ overloads:

https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#vector-data-load-and-store-functions

```
gentypen vloadn(size_t offset, const __global gentype *p)
gentypen vloadn(size_t offset, const __local gentype *p)
gentypen vloadn(size_t offset, const __constant gentype *p)
gentypen vloadn(size_t offset, const __private gentype *p)

For OpenCL C 2.0, or OpenCL C 3.0 or newer with the __opencl_c_generic_address_space feature:

gentypen vloadn(size_t offset, const gentype *p)
```

It seems currently we require extra overloads with the specific named address spaces (global, local, private) to be available along with generic ones in OpenCL 2.0 drivers while before it was not the case. It is believed to be transparent to the application code but it is a problem for the implementation especially the common parts like parser because it is not clear how to resolve the disputes of what is the right behavior.

**Potential resolutions:**
- Update one of the specs to be coherent with another.
- Provide a statement of how the disputes should be resolved i.e. should the latest spec take the presedence?

Contributor guide

Open the contributing guide

Research direction

Start with the linked vloadn sections in the OpenCL C 2.2 and 3.0 unified specifications, then compare their generic and named address-space overloads for OpenCL 2.0. Resolve which behavior is authoritative with the specification maintainers, and update the relevant specification text or add explicit guidance so implementations can apply one consistent rule.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.