Merge pull request #1003 from coldav/colin/update_emails

[DOCUMENTATION] General tidy ups of email addresses and links

Author: Colin Davidson

CODE_OF_CONDUCT.md

@@ -53,21 +53,6 @@ or acting as an appointed representative at an online or offline event.
 Representation of a project may be further defined and clarified by project
 maintainers.
 
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at
-[oneapi.construction.kit@codeplay.com](mailto:oneapi.construction.kit@codeplay.com).
-All complaints will be reviewed and investigated and will result in a response
-that is deemed necessary and appropriate to the circumstances. The project team
-is obligated to maintain confidentiality with regard to the reporter of an
-incident.  Further details of specific enforcement policies may be posted
-separately.
-
-Project maintainers who do not follow or enforce the Code of Conduct in good
-faith may face temporary or permanent repercussions as determined by other
-members of the project's leadership.
-
 ## Attribution
 
 This Code of Conduct is adapted from the [Contributor
@@ -76,7 +61,5 @@ https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
 
 ---
 
-If there are any issues or suggestions relating to the current set of rules,
-you can reach us at
-[oneapi.construction.kit@codeplay.com](mailto:oneapi.construction.kit@codeplay.com).
-
+If there are any issues or suggestions relating to the current set of rules, you
+can reach us by raising a [github issue](https://github.com/uxlfoundation/oneapi-construction-kit/issues).

CONTRIBUTING.md

@@ -33,9 +33,7 @@ where appropriate.
 This project and everyone participating in it are governed by the [oneAPI
 Construction Kit Code of Conduct](blob/main/CODE_OF_CONDUCT.md). By
 participating, you are expected to uphold this code and use your best judgement
-where it's unclear if your behaviour would violate the code. Please report
-unacceptable behaviour to
-[oneapi.construction.kit@codeplay.com](mailto:oneapi.construction.kit@codeplay.com).
+where it's unclear if your behaviour would violate the code.
 
 # I want to contribute
 
@@ -86,7 +84,7 @@ with potential bugs as quickly and as smoothly as possible.
 If you have discovered a security vulnerability, sensitive information leak, or
 a similar security-related issue, please do **not** report this directly to the
 issue tracker. Instead, please send your report by email to
-[oneapi.construction.kit@codeplay.com](mailto:oneapi.construction.kit@codeplay.com),
+[security@uxlfoundation.org](mailto:security@uxlfoundation.org),
 making sure to write `DISCLOSURE:` at the beginning of the subject line so that
 we can prioritize accordingly.
 
@@ -125,7 +123,7 @@ in preparation for your suggestion.
   the
   [main branch](https://github.com/uxlfoundation/oneapi-construction-kit/blob/main).
 * Read the
-  [Documentation](https://developer.codeplay.com/products/oneapi/construction-kit/guides)
+  [Documentation](https://uxlfoundation.github.io/oneapi-construction-kit/doc)
   carefully and make sure your suggested functionality is not already covered
   by the project or by an individual configuration of the project.
 * Check to see if the enhancement has already been suggested in
@@ -230,10 +228,4 @@ maintainers to review your changes.
 
 Once again, thank you for expressing interest in contributing to the project.
 If you'd like to contribute in any way but are unclear on the guidelines listed
-above, please don't hesitate to get in touch by [asking a
-question](#i-have-a-question).
-
-Finally, if you would like to get in touch with us directly to discuss the
-oneAPI Construction Kit, please contact
-[oneapi.construction.kit@codeplay.com](mailto:oneapi.construction.kit@codeplay.com)
-and include all relevant details.
+above, please read [Support](README.md#support).

README.md

@@ -28,7 +28,7 @@ and external components.
    oneAPI Construction Kit was previously referred to as ComputeAorta and referred to as acronym `CA`. As a result, references to ComputeAorta or CA may be present in some oneAPI Construction Kit's documentation and code.
 
 ## Get started with the oneAPI Construction Kit
-This section provides the minimum system requirements for building the oneAPI Construction Kit on Ubuntu 22.04. For Windows platform dependencies and build instructions please refer to the [developer guide](doc/developer-guide.md). There is a [blog post](https://codeplay.com/portal/blogs/2023/06/05/introducing-the-oneapi-construction-kit) demonstrating how to build the kit for a simulated RISC-V target. You can also find the documentation on [Codeplay's developer website](https://developer.codeplay.com/products/oneapi/construction-kit/home/).
+This section provides the minimum system requirements for building the oneAPI Construction Kit on Ubuntu 22.04. For Windows platform dependencies and build instructions please refer to the [developer guide](doc/developer-guide.md). There is a [blog post](https://web.archive.org/web/20250516110421/https://codeplay.com/portal/blogs/2023/06/05/introducing-the-oneapi-construction-kit) demonstrating how to build the kit for a simulated RISC-V target.
 
 ### Platform Dependencies
 * [GCC](https://gcc.gnu.org/)
@@ -400,7 +400,7 @@ If you would like to open a new question, we ask that you follow these steps:
 Once your question has been opened, we will take a look and try to help you as
 soon as possible.
 
-[Documentation]: https://developer.codeplay.com/products/oneapi/construction-kit/guides
+[Documentation]: https://uxlfoundation.github.io/oneapi-construction-kit/doc
 [GitHub Discussions Q&A]: https://github.com/uxlfoundation/oneapi-construction-kit/discussions/categories/q-a
 [GitHub Issues]: https://github.com/uxlfoundation/oneapi-construction-kit/issues
 

doc/modules/builtins/libimg.md

@@ -233,42 +233,3 @@ be generated.
 ```
 -DCODEPLAY_IMG_ENABLE_DOCUMENTATION=ON
 ```
-
-## ComputeCpp Integration
-
-A quick overview of the road map for IMG integration with ComputeCpp.
-
-### IMG requires
-
-* A header containing typedef's of ComputeCpp vector types.
-  * This is to be included in the image functions header file.
-  * The naming convention for the vector typedefs is to prefix the OpenCL C
-    vector type names with two underscores such as `__float4`.
-* A header containing vector element access functions.
-  * This is to generalise access to vector elements between the OpenCL C
-    appraoch and the SYCL appraoch.
-  * The naming convention for vector access functions is to declare the
-    functions in the `img` namespace such as `float img::get(float4 &v, int i)`.
-* A header containing wrappers around ComputeCpp built-in functions.
-  * This is to be included in the image functions source file.
-  * The naming convention for the function declarations is to declare the
-    functions in the `img` namespace such as `int2 img::clamp(int2 x, int2
-    minval, int2 maxval)`.
-  * May require the provision of a library path to link with to access the
-    built-in function definitions.
-
-### IMG provides
-
-* A list of required built-in functions it depends on.
-  * List is TBD.
-* A header declaring the image library functions.
-  * This is to be included by ComputeCpp to implement the SYCL image host
-    fallback.
-* A static library defining the image library functions.
-  * Provides the definitions of the IMG image library functions.
-
-### IMG does not provide
-
-* The SYCL function types to be used in the image host fallback.
-  * The intention is for ComputeCpp to wrap the IMG declarations in inline
-    functions.

doc/overview/example-scenarios/mapping-custom-instructions-to-builtin-functions.rst

@@ -108,15 +108,14 @@ Creating and exposing new custom builtins so that they can be used from SYCL
 kernels follows a similar process to OpenCL, with some differences.
 Builtin declarations can be added to a C++ SYCL header that is specific to the
 target. This header needs to be explicitly included by the kernel source file
-and used by the ComputeCpp device compiler to generate declarations for these
+and used by the DPC++ device compiler to generate declarations for these
 builtin functions when compiling the kernel to SPIRV.
 
-SPIR-V code generated by ComputeCpp is then translated into LLVM IR by
+SPIR-V code generated by DPC++ is then translated into LLVM IR by
 the oneAPI Construction Kit and passed to the ComputeMux target. From that
 point on, the compilation process is the same for custom builtins exposed
 through OpenCL and SYCL. A LLVM pass is needed to translate custom builtin
 calls to compiler intrinsics.
 
 In some cases, SPIR-V extensions to add new custom SPIR-V opcodes **may**
-be necessary. Please refer to the ComputeCpp documentation for more details on
-the SPIR-V compilation process.
+be necessary.

doc/overview/example-scenarios/refsi-in-kernel-dma.rst

@@ -6,7 +6,7 @@ simulator, the RISC-V target supports a mechanism that allows kernels to perform
 data transfers between different kinds of simulated memory. This feature is
 called RefSi In-Kernel DMA and it serves as an example of how
 accelerator-controlled DMA can be integrated in the oneAPI Construction Kit and
-ComputeCpp for existing hardware. DMA transfers can be configured, started and
+oneAPI toolchain for existing hardware. DMA transfers can be configured, started and
 waited for through an interface consisting of memory-mapped registers. The current
 implementation simulates memory transfers at a high level, not taking into
 account memory bandwidth nor being tied to the RISC-V pipeline.

doc/overview/introduction/architecture.rst

@@ -262,15 +262,12 @@ oneAPI Construction Kit is designed to slot into a `SYCL`_ technology stack, as
 `SYCL Backend`_, or oneAPI Construction Kit can be used to write an implementation of 
 SYCL directly to a system or device.
 
-oneAPI Construction Kit has thoroughly tested integration with `ComputeCpp`_, Codeplay's
+oneAPI Construction Kit has thoroughly tested integration with `DPC++`_, Intel's
 implementation of the `SYCL 1.2.1`_ and `SYCL 2020`_ specifications. This
 allows `SYCL`_ applications to be run through oneAPI Construction Kit, encouraging the
 development of OpenCL extensions and optimizations in oneAPI Construction Kit that are of
 benefit to software using `SYCL`_.
 
-To learn more about ComputeCpp see the :doc:`ComputeCpp Overview
-</computecpp>`.
-
 .. _SYCL:
   https://www.khronos.org/sycl
 .. _SYCL 1.2.1:
@@ -279,5 +276,3 @@ To learn more about ComputeCpp see the :doc:`ComputeCpp Overview
   https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html
 .. _SYCL Backend:
   https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_the_sycl_backend_model
-.. _ComputeCpp:
-  https://developer.codeplay.com/products/computecpp/ce/home

doc/overview/preface.rst

@@ -17,11 +17,6 @@ requirements it places on that hardware or software.
 
 Related documents that you may have access to include:
 
-* ComputeCpp Overview
-* `ComputeCpp User Guides`_
 * ComputeMux Specifications
 * HAL Specification
 * oneAPI Construction Kit Reference Documentation
-
-.. _ComputeCpp User Guides:
-  https://developer.codeplay.com/products/computecpp/ce/guides/#computecpp

doc/overview/reference-silicon/overview.rst

@@ -16,8 +16,7 @@ where the "Host CPU" offloads the key computations to an accelerator.
 
 The platform is meant as an example for how Acoran maps to hardware with similar
 components and features. It is used to demonstrate how such hardware
-features can be integrated within Acoran components such as ComputeCpp,
-oneAPI Construction Kit and libraries such as SYCL-BLAS and SYCL-DNN.
+features can be integrated with toolchains such as provided by oneAPI.
 
 In this section we will describe the first version RefSi Accelerator
 architecture (RefSi M1), its components and how these components interact. A