Skip to content

[SYCL][DOC] Refactor OCL global variable spec #5659

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 1, 2022
Merged

[SYCL][DOC] Refactor OCL global variable spec #5659

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c621701
[SYCL][DOC] Refactor OCL global variable spec
gmlueck Feb 24, 2022
39cad4d
Tweak wording to clarify this applies to SPIR-V
gmlueck Feb 28, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 27 additions & 16 deletions sycl/doc/design/opencl-extensions/cl_intel_global_variable_access.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -147,22 +147,10 @@ cl_int clEnqueueWriteGlobalVariableINTEL(
_program_ must define a global variable identified by _name_.

* _name_ identifies the global variable to read or write. Must be non-NULL.
The interpretation depends on how _program_ was created:

** If _program_ was created with *clCreateProgramWithIL* from SPIR-V, there are
two cases:

*** If the SPIR-V module declares the *GlobalVariableDecorationsINTEL*
capability, the implementation looks first for an *OpVariable* that is
decorated with *HostAccessINTEL* where the _Name_ operand is the same as
_name_.

*** The implementation next looks for an *OpVariable* that is decorated with
*LinkageAttributes* where the _Linkage Type_ is *Export* and the _Name_
operand is the same as _name_.

** If _program_ was created in any other way, the interpretation of
_name_ is implementation-defined.
The interpretation depends on how _program_ was created, so see the
appropriate environment specification for details. (For example, if
_program_ was created from SPIR-V, see the OpenCL SPIR-V Environment
Specification.)

* _blocking_read_ and _blocking_write_ indicate if the read and write
operations are _blocking_ or _non-blocking_ (see below).
Expand Down Expand Up @@ -292,6 +280,29 @@ Add two new rows to Table 37, *List of supported event command types*:
|===


== Modifications to the OpenCL SPIR-V Environment Specification

=== New Section "Global Variables"

Add a new subsection under section 2, *Common Properties* named *Global
Variables* with the following content:

Host code may read or write the content of a global variable in a `cl_program`
by calling *clEnqueueReadGlobalVariableINTEL* or
*clEnqueueWriteGlobalVariableINTEL*. Those two functions both take a _name_
parameter which identifies the variable. For a `cl_program` created from
SPIR-V, this parameter is interpreted as follows:

* If the SPIR-V module used to create _program_ declares the
*GlobalVariableDecorationsINTEL* capability, the implementation looks first
for an *OpVariable* that is decorated with *HostAccessINTEL* where the _Name_
operand is the same as _name_.

* The implementation next looks for an *OpVariable* that is decorated with
*LinkageAttributes* where the _Linkage Type_ is *Export* and the _Name_
operand is the same as _name_.


== Issues

. We do not have a formal definition for the _name_ of a global variable when
Expand Down