KhronosGroup / KhronosGroup/OpenCL-Docs

Improve wording about the optionality of image types

Open
#633 1 comment 0 reactions 0 assignees View on GitHub
OpenCL C Spec
Dominant language
Python
Stars
420
Forks
131
Avg merge
5d 13h
Merged PRs (30d)
11

Description

Spec says the following about image types

> The image2d_t, image3d_t, image2d_array_t, image1d_t, image1d_buffer_t, image1d_array_t, image2d_depth_t, image2d_array_depth_t and sampler_t types are only defined if the device supports images, i.e. the value of the CL_DEVICE_IMAGE_SUPPORT device query) is CL_TRUE.

where `defined` appears to be confusing since all those are reserved identifiers (https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#keywords) and therefore are always recognized by the implementations.

As a matter of fact, clang doesn't implement the optionality of images correctly as they are always available regardless the macro. The behavior is now being changed for OpenCL 3.0 only.

Could we change the wording to use `supported` instead? This will align better with other optional types e.g. doubles

> The double scalar type is an optional type that is supported if the value of the CL_DEVICE_DOUBLE_FP_CONFIG device query is not zero. If this is the case then an OpenCL C 3.0 compiler must also define the __opencl_c_fp64 feature macro.

Contributor guide

Open the contributing guide

Research direction

Start with the OpenCL C specification passage describing image and sampler types, then compare its wording with the cited optional double type text. Done means the image-type wording clearly describes support and remains consistent with the specification's treatment of other optional types.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.