KhronosGroup / KhronosGroup/OpenCL-Docs

Use of extensions in the kernel language

Open
#82 17 comments 0 reactions 0 assignees View on GitHub

@AnastasiaStulova is already working on this.

Since Jul 20, 2020.

  • #355 by @AnastasiaStulova — open
needs-cts-coverage OpenCL C Spec themed-agenda
Dominant language
Python
Stars
421
Forks
132
Avg merge
5d 13h
Merged PRs (30d)
11

Description

I would like to summarize the intended use of extension (after my discussion with @bashbaug) and if possible adjust the implementation.

A. The way to check that the extension is being supported is by predefined extension macro i.e.

#if defined(cl_khr_subgroups)
size_t i = get_sub_group_local_id();
#endif

B. Some extensions might require extra compiler support or alter traditional compilation phase. When different compilation functionality is required it can be enabled using pragma. I.e.

#pragma OPENCL EXTENSION cl_khr_fp64 : enable
cos(0.1); //use cos overload with double.
#pragma OPENCL EXTENSION cl_khr_fp64 : disable
cos(0.1); //use cos overload with float.

Observation: the use of get_sub_group_local_id doesn't require any compilation support and can be handled as regular include and therefore no extension pragma is needed to use the function. The same applies to cos. Only the use of double literal requires enabling pragma in the above examples.

This doesn't align with upstream implementation in Clang. The implementation requires extension pragma for some extensions that are not part of core support in corresponding spec version i.e. pragma will be required for subgroups up to OpenCL v2.0. The implementation is quite inconsistent though. For example some extensions from ARM and Intel require pragma but extensions from AMD don't seem to be requiring it.

Actions:
1. Gather the list of extensions that require pragma
2. Simplify compilation by not requiring pragma where it is not necessary.

Backwards compatibility: Old code will continue to compile. Pragma will be simply ignored by the new rules.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review the linked pull request #355 and compare the issue's extension-macro and pragma examples with the corresponding upstream Clang behavior. First gather which extensions require pragmas, then verify that unnecessary pragmas are no longer required while existing code remains compatible. Done means the extension rules are documented or implemented consistently with the stated actions.

Written by the indexing model from the issue text.

Assessment

Domain
compilers
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.