|
| 1 | +--- |
| 2 | +rfc: 3 |
| 3 | +title: Removing support for Vulkan |
| 4 | +author: Colin Davidson <[email protected]> |
| 5 | +discussions-to: https://github.com/uxlfoundation/oneapi-construction-kit/discussions/670 |
| 6 | +status: draft |
| 7 | +--- |
| 8 | + |
| 9 | +<details markdown="1"> |
| 10 | +<summary>Table of Contents</summary> |
| 11 | +* Table of Contents |
| 12 | +{:toc} |
| 13 | +</details> |
| 14 | + |
| 15 | +# Abstract |
| 16 | + |
| 17 | +Vulkan API is incomplete and requires installing Vulkan SDK, as well as being |
| 18 | +enabled by default. It has a maintenance and design overhead and is not being |
| 19 | +used, as well as leading to customer confusion. It is proposed that it should be |
| 20 | +removed in its entirety. |
| 21 | + |
| 22 | +# Motivation |
| 23 | + |
| 24 | +Support for Vulkan is incomplete and cannot be used for full Vulkan support. It |
| 25 | +is not being used anywhere at present and leads to requirement on installing the |
| 26 | +Vulkan SDK in order to build OCK. This is also enabled by default and has led to |
| 27 | +confusion among users of OCK, particularly in the requirements for building. It also |
| 28 | +leads to strange dependency such as the mutex which doesn't really belong in the |
| 29 | +`compiler_pipeline` passes. |
| 30 | + |
| 31 | +# Rationale |
| 32 | + |
| 33 | +By removing it altogether this avoids any confusion on the part of the user and |
| 34 | +reduces the maintenance overhead. |
| 35 | + |
| 36 | +# Specification |
| 37 | + |
| 38 | +Remove everything under source/vk and from all documentation that refers to it, |
| 39 | +as well as any github workflow or docker requirements such as installing the |
| 40 | +vulkan SDK. This should also be reflected in the CHANGELOG.md file ready for the |
| 41 | +release notes. |
| 42 | + |
| 43 | +# Backwards Compatibility |
| 44 | + |
| 45 | +Since the Vulkan API will no longer be supported, there will be no backward |
| 46 | +compatibility in this regard. However the default build will still work for the |
| 47 | +OpenCL API, so current customers are unlikely to be affected. |
| 48 | + |
| 49 | +# Security Implications |
| 50 | + |
| 51 | +None |
| 52 | + |
| 53 | +# How to Teach This |
| 54 | + |
| 55 | +This should be added to the next release notes. |
| 56 | + |
| 57 | +# Reference Implementation |
| 58 | + |
| 59 | +The reference implementation is |
| 60 | +[here](https://github.com/uxlfoundation/oneapi-construction-kit/pull/648). Note |
| 61 | +this makes the majority of the changes necessary, but is not complete and there |
| 62 | +are some TODOs to check. |
| 63 | + |
| 64 | +# Rejected Ideas |
| 65 | + |
| 66 | +We could keep it as is but have it disabled by default and only test it in our |
| 67 | +nightly testing. Although this has its merits, the author feels that Vulkan is |
| 68 | +of little benefit as is and we would get an overall lowering of our maintenance |
| 69 | +by dropping it altogether. Having something but not testing it leads to bitrot |
| 70 | +and inability to know whether a change breaks anything. We could do a very |
| 71 | +specific test overnight though as a possibility if we want to keep it disabled |
| 72 | +by default. |
| 73 | + |
| 74 | +# Open Issues |
| 75 | + |
| 76 | +None |
| 77 | + |
| 78 | +# Footnotes |
| 79 | + |
| 80 | +None |
| 81 | + |
| 82 | +# Copyright |
| 83 | + |
| 84 | +This document is placed in the public domain or under the |
| 85 | +CC0-1.0-Universal license, whichever is more permissive. |
0 commit comments