DRAFT: Reference removal of Vulkan SDK dependency

LICENSE.txt

@@ -235,9 +235,6 @@ The OpenCL Intercept Layer
 (https://github.com/intel/opencl-intercept-layer.git) may be fetched under the
 build directory and is held under its own licensing terms.
 
-The source/vk/external/Khronos folder (Khronos Vulkan headers), if present, is
-held under its own licensing terms.
-
 The modules/spirv-ll/external/SPIRV-Headers folder (Khronos SPIR-V headers), if
 present, is held under its own licensing terms.
 

README.md

@@ -4,14 +4,14 @@
 
 # oneAPI Construction Kit
 
-The oneAPI Construction Kit is a framework to provide implementations of open standards, such as OpenCL and Vulkan, for a wide range of devices. The oneAPI Construction Kit can be used to build with the oneAPI Toolkit. The oneAPI Toolkit includes support for various open standards, such as OpenMP, SYCL, and DPC++. DPC++ is based on the SYCL programming model, which allows to write single-source C++ code that can target both CPUs and GPUs. To get more information on oneAPI, please visit https://www.intel.com/content/www/us/en/developer/tools/oneapi/overview.html.
+The oneAPI Construction Kit is a framework to provide implementations of open standards, such as OpenCL, for a wide range of devices. The oneAPI Construction Kit can be used to build with the oneAPI Toolkit. The oneAPI Toolkit includes support for various open standards, such as OpenMP, SYCL, and DPC++. DPC++ is based on the SYCL programming model, which allows to write single-source C++ code that can target both CPUs and GPUs. To get more information on oneAPI, please visit https://www.intel.com/content/www/us/en/developer/tools/oneapi/overview.html.
 
 The oneAPI Construction Kit is part of the [UXL Foundation].
 
 [UXL Foundation]: http://www.uxlfoundation.org
 
 >**_Note:_**
- It is not intended to be used as a standalone OpenCL or Vulkan implementation. It does not support the oneAPI Level Zero API.
+ It is not intended to be used as a standalone OpenCL implementation. It does not support the oneAPI Level Zero API.
 
 For more information about building, implementing and maintaining the oneAPI Construction Kit please take the time to read the [developer guide](doc/developer-guide.md) and the other documentation in the
 `doc` directory.

doc/cmake.rst

@@ -86,15 +86,15 @@ hardware is unavailable.
 Shared Library Naming and Versioning
 ####################################
 
-Both OpenCL and Vulkan APIs are designed to work through an ICD loader, a
-shared library named ``OpenCL`` and ``Vulkan`` respectively in the form
+Both OpenCL APIs are designed to work through an ICD loader, a
+shared library named ``OpenCL`` respectively in the form
 ``lib<name>.so`` or ``<name>.dll``, depending on if the platform is Linux or
 Windows. The ICD loaders gets linked to application code so that at runtime the
 ICD loader will select the implementation of the standard to run
 and load the chosen shared library, allowing multiple platforms to coexist on
 the same system.
 
-To avoid naming collisions with the ICD our OpenCL and Vulkan builds by default
+To avoid naming collisions with the ICD our OpenCL builds by default
 are named ``CL`` and ``VK``, however these can be overridden via the
 ``CA_CL_LIBRARY_NAME`` and ``CA_VK_LIBRARY_NAME`` options. Providing customer
 teams with the flexibility to deliver on embedded systems without an ICD loader,
@@ -108,11 +108,9 @@ versioning properties, a `VERSION`_ property for the build version and a
 ``major.minor``, where the major component is incremented on API breaking
 changes and minor for non-breaking API changes, e.g bug fixes. The `SOVERSION`_
 property can then be set as the major component of `VERSION`_. We default
-`VERSION`_ for both OpenCL and Vulkan to our oneAPI Construction Kit
+`VERSION`_ for both OpenCL to our oneAPI Construction Kit
 `PROJECT_VERSION`_, but provide the ``CA_CL_LIBRARY_VERSION`` option to
-override that behavior for OpenCL. We don't provide an equivalent CMake
-library version option for Vulkan as simulating the ICD loader is a use
-case that we have yet to encounter.
+override that behavior for OpenCL.
 
 On Linux an OpenCL build with our default options will result in the following
 symbolic links being created to the fully qualified shared library.

doc/design.md

@@ -9,7 +9,7 @@ within the directory structure.
 
 A common structure is used as much as possible throughout the oneAPI
 Construction Kit repository. Implementations of open standards, such as
-OpenCL and Vulkan, exist as subdirectories of the `source` directory and
+OpenCL, exist as subdirectories of the `source` directory and
 shared components, or modules, reside in the `modules` directory.
 
 Throughout the repository the following layout is adhered to when applicable:

doc/developer-guide.md

@@ -14,15 +14,12 @@ Kit build then uses this installation as a dependency.
 Current directory layout:
 
 * `source`: Contains source specific to implementing open standards, such as
-  OpenCL and Vulkan.
+  OpenCL.
   * `source/cl`: Encapsulates all source code which implements the OpenCL open
     standard, this is an optional component and may not be present dependent on
     license agreement.
     * `source/cl/source/extension/include`: This directory holds the headers
       for the Codeplay specific OpenCL extensions.
-  * `source/vk`: Encapsulates all source code which implements the Vulkan open
-    standard, this is an optional component and may not be present dependent on
-    license agreement.
 * `modules`: Contains shared _modules_ used in the implementation of the open
   standards in `source`. For details on the _modules_ layout in the [modules
   documentation](modules.md). Currently we have the following modules:
@@ -254,7 +251,7 @@ The builtin CMake options used when invoking CMake on the command line.
   a supported LLVM version.
 
 * `CA_ENABLE_API`: Semi-colon separated list of APIs to enable. Valid values
-  are `cl` for OpenCL, and `vk` for Vulkan. Enabling an API when an optional
+  are `cl` for OpenCL. Enabling an API when an optional
   component is not present dependent on license agreement will result in a CMake
   error. The default is `cl;vk`.
 
@@ -315,7 +312,7 @@ The builtin CMake options used when invoking CMake on the command line.
  `RPATH` for all targets when they are installed using `CMAKE_INSTALL_RPATH`,
   this ensures that when the `install` target is invoked the user does not need
   to specify `LD_LIBRARY_PATH` to correctly execute a test binary in order to
-  use the installed OpenCL or Vulkan library. Do disable this behaviour set
+  use the installed OpenCL library. Do disable this behaviour set
   `-DCMAKE_SKIP_RPATH=ON` when configuring CMake in build directory.
 
 * `CA_HOST_TARGET_<arch>_CPU`, `CA_HOST_TARGET_<arch>_FEATURES`: These options
@@ -374,7 +371,7 @@ The builtin CMake options used when invoking CMake on the command line.
 
 #### oneAPI Construction Kit CMake Build Targets
 
-* `ComputeAorta`: Build the OpenCL and Vulkan libraries, if present, and all
+* `ComputeAorta`: Build the OpenCL libraries, if present, and all
   their test suites.
 * `check-ock`/`check-ock-<target>`: Build and run all short running test
   suites, this selection of testing is used by continuous integration to verify
@@ -407,13 +404,6 @@ The builtin CMake options used when invoking CMake on the command line.
 * `check-ock-cl`: Build and run various OpenCL test suites, primarily UnitCL and
   selected short running OpenCL CTS tests.
 
-##### oneAPI Construction Kit Vulkan CMake Build Targets
-
-* `VK`: Build only the Vulkan library, only available when Vulkan is enabled.
-* `UnitVK`: Build the UnitVK test suite, as well as the Vulkan library.
-* `VKICDManifest`: Generates the Vulkan ICD manifest, Linux only.
-* `check-ock-vk`: Build and run UnitVK and spirv-ll lit tests.
-
 ## Compiling
 
 ### Compiling LLVM
@@ -644,8 +634,7 @@ cmake --build %CD%\build-x86_64-Debug --target check --config Debug
 
 Compiling the oneAPI Construction Kit without LLVM is also referred to as an
 offline-only configuration or disabling the runtime compiler. In this mode the
-oneAPI Construction Kit does not include a JIT compiler for OpenCL, offline-only
-is currently not supported for Vulkan and is disabled in the configuration.
+oneAPI Construction Kit does not include a JIT compiler for OpenCL.
 
 #### Compiling the oneAPI Construction Kit without LLVM on Linux
 

doc/getting-started.rst

@@ -120,7 +120,6 @@ configuration.
 * `Git`_
 * `CMake`_ 3.4.3+
 * `Python`_ 3.6.9+
-* `Vulkan SDK`_ 1.1.97+
 
 Windows 10 does not provide an adequate package manager. However, the
 third-party `Chocolatey <https://chocolatey.org/install#install-with-cmdexe>`_
@@ -168,53 +167,20 @@ Windows 11
 
 Windows 11 is supported, but has not been tested to the same level as Windows 10.
 
-Vulkan SDK
-----------
-
-For Vulkan support the Vulkan SDK is required to be installed. It can be
-acquired from `LunarG <https://www.lunarg.com/vulkan-sdk/>`_. The latest version
-should always be supported. The minimum supported version is 1.1.97.
-
-The Vulkan SDK includes `SPIRV-Tools`_ as part of the package. Therefore
-`SPIRV-Tools`_ does not need to be installed separately.
-
 Package Manager Installation
 ............................
 
-Users of Ubuntu 20.04 and later should configure their apt package manager to
-install the Vulkan SDK packages directly as described by the `LunarG Vulkan SDK
-packages`_ page. This installation method does neither set nor require the
-:envvar:`VULKAN_SDK` environment variable, avoiding the configuration
-complexities experienced when installing manually.
-
+SPIRV-Tools is needed to build the OneAPI Construction Kit. This can either come from Vulkan
+SDK OR installing spirv tools directly. On windows, we suggest installing the vulkan SDK>.
 Windows users should install directly from `LunarG
 <https://www.lunarg.com/vulkan-sdk/>`_, as at the time of writing the Vulkan SDK
 cannot be installed through Chocolatey.
 
-Manual Installation
-...................
-
-Other Linux users will need to take some extra steps after downloading the
-tarball distribution. First run the ``build_tools.sh`` script; then source the
-``setup-env.sh`` script whilst the Vulkan SDK directory as the current
-directory. These steps are needed to access the ``spirv-as`` tool through the
-:envvar:`VULKAN_SDK` environment variable in order to successfully compile
-the oneAPI Construction Kit and generate all test suites correctly.
-
-.. hint::
-   Modifying ``.bashrc`` to source the ``setup-env.sh`` script avoids having to
-   remember to do this on every new terminal session building the oneAPI
-   Construction Kit.
-
-The ``setup-env.sh`` script prepends :envvar:`VULKAN_SDK` to the system
-:envvar:`PATH`, leading to prioritization of :envvar:`VULKAN_SDK` binaries
-ahead of any other versions of the tools which may be installed in ``/usr/bin``.
 
 SPIRV-Tools
 -----------
 
-When OpenCL support is required but Vulkan support is not, `SPIRV-Tools`_
-**may** optionally be installed on the system :envvar:`PATH`. This is
+`SPIRV-Tools`_ **may** optionally be installed on the system :envvar:`PATH`. This is
 recommended to achieve good coverage of SPIR-V compilation paths.
 
 Follow the build instructions, or install the pre-built binaries in the

doc/index.rst

@@ -6,14 +6,14 @@ The documentation herein refers to version |release| of the oneAPI Construction
 The heterogeneous language toolkit.
 ===================================
 
-The oneAPI Construction Kit is a framework to provide implementations of open standards, such as OpenCL and Vulkan,
+The oneAPI Construction Kit is a framework to provide implementations of open standards, such as OpenCL,
 for a wide range of devices. The oneAPI Construction Kit can be used to build with the oneAPI Toolkit. The oneAPI Toolkit
 includes support for various open standards, such as OpenMP, SYCL, and DPC++. DPC++ is based on the SYCL programming
 model, which allows to write single-source C++ code that can target both CPUs and GPUs. To get more information on oneAPI,
 please visit `oneAPI <https://www.intel.com/content/www/us/en/developer/tools/oneapi/overview.html>`_.
 
 .. note::
- It is not intended to be used as a standalone OpenCL or Vulkan implementation. It does not support the oneAPI Level Zero API.
+ It is not intended to be used as a standalone OpenCL implementation. It does not support the oneAPI Level Zero API.
 
 .. toctree::
     :maxdepth: 3

doc/modules/mux.rst

@@ -185,7 +185,7 @@ would increase build time and bloat the final binary. The way
 capabilities are handled in the build system may not be immediately
 obvious because of the number of CMake variables and the number of
 components involved. Capability-related variables are present in Abacus
-builtins, Mux, and all Mux target devices. The OpenCL and Vulkan
+builtins, Mux, and all Mux target devices. The OpenCL
 implementations (``source/cl`` and ``source/vk``) do not rely on
 capability variables, as they need to generically support more than one
 Mux device, each with potentially different capabilities, at the same

doc/modules/mux/cmake.rst

@@ -7,7 +7,7 @@ build.
 
 ``modules/mux/CMakeLists.txt`` creates a static library target ``mux`` using
 :cmake:command:`add_ca_library` that frontend APIs implemented by the oneAPI
-Construction Kit, such as OpenCL and Vulkan, build on. ComputeMux library code
+Construction Kit, such as OpenCL, build on. ComputeMux library code
 provides entry points to the Mux API which perform implementation agnostic error
 checking of argument invalid usage, and then direct control flow through to a
 desired Mux implementation. The :cmake:variable:`CA_MUX_ENABLE_SHARED` option can

doc/overview/compiler/computemux-compiler.rst

@@ -20,7 +20,7 @@ LLVM
 
 The ComputeMux Compiler hides its usage of LLVM behind a set of virtual
 interfaces. This avoids the need for an open standards implementation linking
-with the oneAPI Construction Kit, such as OpenCL and Vulkan, to also link with
+with the oneAPI Construction Kit, such as OpenCL, to also link with
 LLVM, improving encapsulation.
 
 The base implementation of the interfaces, such as ``BaseModule``, are

doc/overview/introduction/architecture.rst

@@ -80,7 +80,7 @@ Host Runtime
 """"""""""""
 
 A ComputeMux Runtime API implementation targeting the CPU device on which the OpenCL
-or Vulkan driver is running. This includes implementation of entry points for:
+ driver is running. This includes implementation of entry points for:
 
 Memory Transfers
   Reading, writing, copying, filling etc. memory buffers/images.
@@ -153,7 +153,7 @@ Host Compiler
 """""""""""""
 
 A ComputeMux Compiler API implementation targeting the CPU device on which the
-OpenCL or Vulkan driver is running.
+OpenCL  driver is running.
 
 Custom Compiler
 """""""""""""""
@@ -176,7 +176,7 @@ Clang
   from the OpenCL API.
 SPIR-V Parser
   An in house SPIR-V to LLVM IR translator for consuming SPIR-V from the OpenCL
-  and Vulkan APIs.
+   API.
 
 Middle End
 """"""""""
@@ -258,8 +258,7 @@ SYCL
 ----
 
 oneAPI Construction Kit is designed to slot into a `SYCL`_ technology stack, as the
-:ref:`overview/introduction/architecture:OpenCL` and
-:ref:`overview/introduction/architecture:Vulkan` APIs exposed can be used as a
+:ref:`overview/introduction/architecture:OpenCL` API exposed can be used as a
 `SYCL Backend`_, or oneAPI Construction Kit can be used to write an implementation of 
 SYCL directly to a system or device.
 
@@ -282,9 +281,3 @@ To learn more about ComputeCpp see the :doc:`ComputeCpp Overview
   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
-
-Vulkan
-------
-
-oneAPI Construction Kit provides a pre-conformant Vulkan driver implementing the compute
-subset of Vulkan 1.0 functionality.

doc/overview/preface.rst

@@ -4,7 +4,7 @@ Preface
 This document provides an introduction to Codeplay's oneAPI Construction Kit.
 It should help the reader understand how to use the oneAPI Construction Kit to
 create a high-performance implementation of open-standards for a processor or
-system, i.e. SYCL, OpenCL, or Vulkan.  This implementation will enable
+system, i.e. SYCL, OpenCL.  This implementation will enable
 programmers to use a well-understood programming model, and allow all parties
 to benefit from the open-standards software ecosystem.
 

doc/overview/runtime/computemux-runtime.rst

@@ -3,7 +3,7 @@ ComputeMux Runtime
 
 The ComputeMux Runtime defines an API providing an interface between hardware
 target-specific code and general implementations of open standards such as
-OpenCL, Vulkan Compute and SPIR-V. Each entry point required for a hardware
+OpenCL and SPIR-V. Each entry point required for a hardware
 target in the Runtime API is specified in the :doc:`ComputeMux Runtime
 Specification </specifications/mux-runtime-spec>`, containing detail on the
 purpose of each entry point, valid usage, and expected error codes.