From 017b9cd564cfd32f0dbd8656dfb8cb19bb9433a0 Mon Sep 17 00:00:00 2001 From: tapplencourt Date: Mon, 22 Jul 2024 14:32:25 -0500 Subject: [PATCH 1/3] remove -heterogeneous --- adoc/chapters/architecture.adoc | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/adoc/chapters/architecture.adoc b/adoc/chapters/architecture.adoc index 499038ca..a9e28098 100644 --- a/adoc/chapters/architecture.adoc +++ b/adoc/chapters/architecture.adoc @@ -16,10 +16,10 @@ can run on either an heterogeneous device or on the <>. 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 <>s for various heterogeneous APIs, +other APIs apart from OpenCL. +SYCL implementations provide <>s for various APIs, implementing the SYCL general specification on top of them. -We refer to this heterogeneous API as the <>. +We refer to this API as the <>. 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 <> 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 @@ -187,7 +187,7 @@ correct. == The SYCL platform model The SYCL platform model consists of a host connected to one or more -heterogeneous devices, called <>. +devices, called <>. <> are grouped together into one or multiple <>. An implementation may also expose empty <> that do not @@ -215,7 +215,7 @@ The <> then extracts operations from the <>. When the operation is a <>, the <> uses a <>-specific mechanism to extract the device binary from the SYCL -application and pass it to the heterogeneous API for execution on the +application and pass it to the <> for execution on the <>. A SYCL <> is divided into one or more compute units (CUs) which are each @@ -241,7 +241,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 <>. @@ -270,7 +270,7 @@ 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 +application is executed exposes support for the API required for the <>. It is implementation dependent whether certain backends require third-party @@ -366,7 +366,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 <> to manage the heterogeneous devices it is +required by the <> 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. From 2d4e8f2467fb86924f44c67993022228775fea2d Mon Sep 17 00:00:00 2001 From: tapplencourt Date: Mon, 22 Jul 2024 14:36:56 -0500 Subject: [PATCH 2/3] forgot to run with -overwrite --- adoc/chapters/architecture.adoc | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/adoc/chapters/architecture.adoc b/adoc/chapters/architecture.adoc index a9e28098..11231875 100644 --- a/adoc/chapters/architecture.adoc +++ b/adoc/chapters/architecture.adoc @@ -17,8 +17,8 @@ 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 APIs apart from OpenCL. -SYCL implementations provide <>s for various APIs, -implementing the SYCL general specification on top of them. +SYCL implementations provide <>s for various APIs, implementing the +SYCL general specification on top of them. We refer to this API as the <>. The SYCL general specification defines the behavior that all SYCL implementations must expose to SYCL users for a SYCL application to behave as @@ -186,8 +186,8 @@ correct. [[sec:platformmodel]] == The SYCL platform model -The SYCL platform model consists of a host connected to one or more -devices, called <>. +The SYCL platform model consists of a host connected to one or more devices, +called <>. <> are grouped together into one or multiple <>. An implementation may also expose empty <> that do not @@ -215,8 +215,7 @@ The <> then extracts operations from the <>. When the operation is a <>, the <> uses a <>-specific mechanism to extract the device binary from the SYCL -application and pass it to the <> for execution on the -<>. +application and pass it to the <> for execution on the <>. A SYCL <> is divided into one or more compute units (CUs) which are each divided into one or more processing elements (PEs). @@ -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 API required for -the <>. +application is executed exposes support for the API required for the +<>. 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 <> to manage the devices it is -providing access to. +required by the <> 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. From 8d6e846ea204c1b383ec49d0f8ac5b7ad4ac2da9 Mon Sep 17 00:00:00 2001 From: Thomas Applencourt Date: Fri, 26 Jul 2024 16:43:39 -0500 Subject: [PATCH 3/3] Update architecture.adoc --- adoc/chapters/architecture.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adoc/chapters/architecture.adoc b/adoc/chapters/architecture.adoc index 11231875..b1555b24 100644 --- a/adoc/chapters/architecture.adoc +++ b/adoc/chapters/architecture.adoc @@ -17,7 +17,7 @@ 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 APIs apart from OpenCL. -SYCL implementations provide <>s for various APIs, implementing the +SYCL implementations can provide <>s for various APIs, implementing the SYCL general specification on top of them. We refer to this API as the <>. The SYCL general specification defines the behavior that all SYCL