Merge branch 'pub/SYCL-2020/master' into gmlueck/reformat-context

.github/workflows/CI.yml

@@ -28,8 +28,8 @@ jobs:
     # Use the Khronos container with the asciidoctor toolchain preinstalled.  We
     # reference the image by its SHA rather than its tag because they sometimes
     # overwrite a tag with a different image (which has a different SHA).  This
-    # SHA corresponds to tag "asciidoctor-spec.20240702".
-    container: khronosgroup/docker-images@sha256:4aab96a03ef292439c9bd0f972adfa29cdf838d0909b1cb4ec2a6d7b2d14a37f
+    # SHA corresponds to tag "asciidoctor-spec.20240727".
+    container: khronosgroup/docker-images@sha256:089687083ceb36483a3917389e4278718ab19c594099634f5dd80e22540c960f
 
     steps:
       # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it

.github/workflows/open_cts_issue.yml

@@ -1,5 +1,15 @@
 name: Open CTS issue for spec changes
-on: pull_request
+on:
+  # We use the pull_request_target trigger to always run the workflow in the context of the base branch,
+  # since this allows us to access repository secrets even if the PR originates from a fork.
+  #
+  # Importantly, the workflow must not checkout any code from the PR branch, as this could allow an attacker
+  # to gain write access to the repository.
+  # See https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ for more information.
+  pull_request_target:
+    types: opened
+    paths:
+      - 'adoc/**'
 jobs:
   create-issue:
     runs-on: ubuntu-latest

README.md

@@ -2,8 +2,8 @@
 
 <!-- to update to newer CI when going public ![Build Status](https://api.travis-ci.com/KhronosGroup/SYCL-Docs.svg?branch=master) -->
 <!-- to update to newer CI when going public [![SPEC master](https://img.shields.io/badge/SPEC-master-red.svg?logo=adobe-acrobat-reader)](https://khronosgroup.github.io/SYCL-Docs/sycl/sycl.pdf) -->
-[![SPEC 2020-8](https://img.shields.io/badge/SPEC-2020--8-orange.svg?logo=adobe-acrobat-reader)](https://www.khronos.org/registry/SYCL/specs/sycl-2020/pdf/sycl-2020.pdf)
-[![SPEC 2020-8](https://img.shields.io/badge/SPEC-2020--8-orange.svg?logo=HTML5)](https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html)
+[![SPEC 2020-9](https://img.shields.io/badge/SPEC-2020--9-orange.svg?logo=adobe-acrobat-reader)](https://www.khronos.org/registry/SYCL/specs/sycl-2020/pdf/sycl-2020.pdf)
+[![SPEC 2020-9](https://img.shields.io/badge/SPEC-2020--9-orange.svg?logo=HTML5)](https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html)
 [![SPEC latest](https://img.shields.io/badge/SPEC-latest-red.svg?logo=adobe-acrobat-reader)](https://github.com/KhronosGroup/SYCL-Docs/actions?query=branch%3ASYCL-2020%2Fmaster+is%3Asuccess)
 [![Join the Slack group](https://img.shields.io/badge/chat-on%20slack-blue.svg?logo=slack)](https://khr.io/slack)
 

adoc/chapters/architecture.adoc

@@ -16,10 +16,10 @@ can run on either an heterogeneous device or on the <<host>>.
 The terminology used for SYCL inherits historically from OpenCL with some
 SYCL-specific additions.
 However SYCL is a generic {cpp} programming model that can be laid out on top of
-other heterogeneous APIs apart from OpenCL.
-SYCL implementations can provide <<backend>>s for various heterogeneous APIs,
-implementing the SYCL general specification on top of them.
-We refer to this heterogeneous API as the <<backend-api>>.
+other APIs apart from OpenCL.
+SYCL implementations can provide <<backend>>s for various APIs, implementing the
+SYCL general specification on top of them.
+We refer to this API as the <<backend-api>>.
 The SYCL general specification defines the behavior that all SYCL
 implementations must expose to SYCL users for a SYCL application to behave as
 expected.
@@ -62,7 +62,7 @@ developers in other fields.
 == Anatomy of a SYCL application
 
 Below is an example of a typical <<sycl-application>> which schedules a job to
-run in parallel on any heterogeneous device available.
+run in parallel on any device available.
 
 // An AsciiDoctor "feature", the language is specified as the second
 // parameter of this attribute, even if we do not want it. So add a
@@ -186,8 +186,8 @@ correct.
 [[sec:platformmodel]]
 == The SYCL platform model
 
-The SYCL platform model consists of a host connected to one or more
-heterogeneous devices, called <<device,devices>>.
+The SYCL platform model consists of a host connected to one or more devices,
+called <<device,devices>>.
 <<device,Devices>> are grouped together into one or multiple <<platform,
 platforms>>.
 An implementation may also expose empty <<platform, platforms>> that do not
@@ -215,8 +215,7 @@ The <<sycl-runtime>> then extracts operations from the
 <<sycl-kernel-function>>.
 When the operation is a <<sycl-kernel-function>>, the <<sycl-runtime>> uses a
 <<backend>>-specific mechanism to extract the device binary from the SYCL
-application and pass it to the heterogeneous API for execution on the
-<<device>>.
+application and pass it to the <<backend-api>> for execution on the <<device>>.
 
 A SYCL <<device>> is divided into one or more compute units (CUs) which are each
 divided into one or more processing elements (PEs).
@@ -241,7 +240,7 @@ programmable kernels, and only support _built-in_ functions.
 == The SYCL backend model
 
 SYCL is a generic programming model for the {cpp} language that can target
-multiple heterogeneous APIs, such as OpenCL.
+multiple APIs, such as OpenCL.
 
 SYCL implementations enable these target APIs by implementing <<backend, SYCL
 backends>>.
@@ -270,8 +269,8 @@ guarantee that said backends can be executed at runtime.
 The subset of active backends available at runtime is called _available
 backends_.
 A backend is said to be _available_ if the host platform where the SYCL
-application is executed exposes support for the heterogeneous API required for
-the <<backend>>.
+application is executed exposes support for the API required for the
+<<backend>>.
 
 It is implementation dependent whether certain backends require third-party
 libraries to be available in the system.
@@ -366,8 +365,7 @@ been satisfied.
 ==== Backend resources managed by the SYCL application
 
 The SYCL runtime integrated with the SYCL application will manage the resources
-required by the <<backend-api>> to manage the heterogeneous devices it is
-providing access to.
+required by the <<backend-api>> to manage the devices it is providing access to.
 This includes, but is not limited to, resource handlers, memory pools, dispatch
 queues and other temporary handler objects.
 

adoc/chapters/information_descriptors.adoc

@@ -11,7 +11,7 @@ introduced in <<chapter:sycl-programming-interface>>.
 == Platform information descriptors
 
 The following interface includes all the information descriptors for the
-[code]#platform# class as described in <<table.platform.info>>.
+[code]#platform# class.
 [source,,linenums]
 ----
 include::{header_dir}/platformInfo.h[lines=4..-1]