@@ -13,15 +13,6 @@ accepted into the project.
1313
1414.. important ::
1515
16- Any contributions that fall into the following criteria *must * follow the
17- `Adapter Change Process `_:
18-
19- * Changing the API/ABI of the specification and or loader.
20-
21- * Changing the implementation of an adapter.
22-
23- * Changing the implementation of shared/common code used by an adapter.
24-
2516 Before making a contribution to the specification you *should * determine if
2617 the change should be made directly to the core specification or introduced
2718 as an experimental feature. The criteria we use to make this distinction
@@ -41,103 +32,24 @@ accepted into the project.
4132 If the feature in question matches any of these criteria, please refer to
4233 the `Experimental Features `_ section, otherwise refer to the `Core
4334 Features `_ section. If you are unsure how to proceed please `create an
44- issue <https://github.com/oneapi-src/unified-runtime /issues/new> `_ asking
45- for clarification.
35+ issue <https://github.com/intel/llvm /issues/new?template=Blank+issue > `_
36+ asking or clarification.
4637
4738 If you are unsure whether a feature can be supported by certain adapters
4839 please seek the advice of an appropriate stakeholder or ask the Unified
4940 Runtime team via the `GitHub issue tracker
50- <https://github.com/oneapi-src/unified-runtime/issues/new> `_.
51-
52- Adapter Change Process
53- ======================
54-
55- 1. Create a pull request containing the adapter changes in the
56- `oneapi-src/unified-runtime `_ project targeting the `main
57- <https://github.com/oneapi-src/unified-runtime/tree/main> `_ branch.
58-
59- .. note ::
60- Historically, convention on the project has been to add one or more
61- ``[COMPONENT] `` prefixes to the pull request title to signify which
62- components are changed within. This is no longer necessary as pull
63- requests are now automatically labeled by the `Pull Request Labeler
64- <https://github.com/oneapi-src/unified-runtime/blob/main/.github/labeler.yml> `_
65- GitHub Action. This approach is less error prone and much easier to
66- filter on the GitHub pull requests tab. Lastly, commit and pull request
67- summaries should strive be short to align with Git convention.
68-
69- 2. Create a draft pull request in the `intel/llvm `_ project to take advantage
70- of the pre-merge testing. Add any required implementation changes in
71- addition to changing:
72-
73- * `UNIFIED_RUNTIME_REPO `_ to point at your fork of Unified Runtime.
74-
75- * `UNIFIED_RUNTIME_TAG `_ to point at your development branch name used to
76- create the Unified Runtime pull request in step 1.
77-
78- 3. Add a comment in the *oneapi-src/unified-runtime * pull request linking to
79- the *intel/llvm * pull request created in step 2.
80-
81- 4. Code reviews for the adapter changes are carried out in the
82- *oneapi-src/unified-runtime * pull request.
83-
84- 5. Any new commits to the *oneapi-src/unified-runtime * pull request *must * be
85- accompanied by a corresponding update in the *intel/llvm * pull request as
86- indicated in step 2, so the testing is always up-to-date.
87-
88- 6. Once the *oneapi-src/unified-runtime * pull request has been approved by at
89- least one member of each relevant code-owner team:
90-
91- * Make the *intel/llvm * pull request ready to review (remove draft) in
92- order to gain approvals from all code-owners to ensure step 8 can
93- progress quickly when the time comes.
94-
95- * Add the *ready to merge * label to the *oneapi-src/unified-runtime * pull
96- request.
97-
98- 7. The Unified Runtime maintainers *must * ensure that step 5 has been carried
99- out and that all pre-merge testing has passed before merging the
100- *oneapi-src/unified-runtime * pull request.
101-
102- * The oldest pull requests with the *ready to merge * label will be
103- prioritized.
41+ <https://github.com/intel/llvm/issues/new?template=Blank+issue> `_.
10442
105- * Contact the Unified Runtime maintainers if a pull request should be
106- given a higher priority.
107-
108- 8. Once the *oneapi-src/unified-runtime * pull request has been merged:
109-
110- * Reverse the change to `UNIFIED_RUNTIME_REPO `_ made in step 2.
111-
112- * Update the `UNIFIED_RUNTIME_TAG `_ to point at the
113- *oneapi-src/unified-runtime * commit/tag containing the merged adapter
114- changes.
115-
116- * Update the pull request description, linking to any other *intel/llvm *
117- pull requests who's changes have been merged into
118- *oneapi-src/unified-runtime * but have not yet been merge into
119- *intel/llvm *.
120-
121- * A Unified Runtime maintainer may facilitate these steps either by
122- making suggestions on the *intel/llvm * pull request or by making those
123- changes directly.
124-
125- .. _oneapi-src/unified-runtime :
126- https://github.com/oneapi-src/unified-runtime
127- .. _intel/llvm :
128- https://github.com/intel/llvm
129- .. _UNIFIED_RUNTIME_REPO :
130- https://github.com/intel/llvm/blob/sycl/sycl/cmake/modules/FetchUnifiedRuntime.cmake#L119
131- .. _UNIFIED_RUNTIME_TAG :
132- https://github.com/intel/llvm/blob/sycl/sycl/cmake/modules/UnifiedRuntimeTag.cmake
43+ When creating issues pertaining the to unified runtime, please include the
44+ [UR] tag in the issue title.
13345
13446Build Environment
13547=================
13648
13749To be able to generate the source from the YAML files, the build environment
13850must be configured correctly and all dependencies must be installed. The
13951instructions for a basic setup are available in the `README
140- <https://github.com/oneapi-src/unified-runtime /blob/main /README.md#building> `_.
52+ <https://github.com/intel/llvm /blob/sycl/unified-runtime /README.md#building> `_.
14153
14254The following additional dependencies are required to support the ``generate ``
14355target:
@@ -183,14 +95,14 @@ You can then follow the instructions below to use the ``generate`` target to
18395regenerate the source.
18496
18597.. _thirdparty/requirements.txt :
186- https://github.com/oneapi-src/unified-runtime /blob/main /third_party/requirements.txt
98+ https://github.com/intel/llvm /blob/sycl/unified-runtime /third_party/requirements.txt
18799.. _.github/docker :
188- https://github.com/oneapi-src/unified-runtime /blob/main /.github/docker
100+ https://github.com/intel/llvm /blob/sycl/unified-runtime /.github/docker
189101
190102Generating Source
191103=================
192104
193- The specification and many other components in the Unified Runtime repository
105+ The specification and many other components in the Unified Runtime project
194106are generated from a set of YAML _ files which are used as inputs to a Mako _
195107based templating system. The YAML file syntax is defined in `YAML syntax `_. To
196108generate the outputs of the Mako templates a build directory must be
@@ -205,7 +117,7 @@ equivalent):
205117YAML : https://yaml.org/
206118.. _Mako : https://www.makotemplates.org/
207119.. _YAML syntax :
208- https://github.com/oneapi-src/unified-runtime /blob/main /scripts/YaML.md
120+ https://github.com/intel/llvm /blob/sycl/unified-runtime /scripts/YaML.md
209121
210122.. note ::
211123
@@ -265,14 +177,16 @@ To submit a pull request to Unified Runtime, you must first create your own
265177personal fork of the project and submit your changes to a branch. By convention
266178we name our branches ``<your_name>/<short_description> ``, where the description
267179indicates the intent of your change. You can then raise a pull request
268- targeting ``oneapi-src/unified-runtime:main ``. Please add the *experimental *
269- label to you pull request.
180+ targeting ``intel/llvm:sycl ``.
181+
182+ Please ensure you include the ``[UR] `` tag in the title of your pull request.
270183
271184When making changes to the specification you *must * commit all changes to files
272- in the repository as a result of `Generating Source `_.
185+ in the project as a result of `Generating Source `_.
273186
274187Before your pull request is merged it *must * pass all jobs in the GitHub
275- Actions workflow and *must * be reviewed by no less than two code owners.
188+ Actions workflow and *must * be reviewed by all reviewer teams tagged as
189+ code-owners.
276190
277191.. hint ::
278192
@@ -308,7 +222,7 @@ OpenMP, ...) where possible although this is a secondary concern.
308222 features in parallel language runtimes.
309223
310224Core features are defined in the ``*.yml `` files in the `scripts/core
311- <https://github.com/oneapi-src/unified-runtime /tree/main /scripts/core> `_
225+ <https://github.com/intel/llvm /tree/sycl/unified-runtime /scripts/core> `_
312226directory. Most of the files are named after the API object who's interface is
313227defined within them, with the following exceptions:
314228
@@ -325,13 +239,13 @@ defined within them, with the following exceptions:
325239* ``scripts/core/exp-<feature>.yml `` see `Experimental Features `_.
326240
327241.. _scripts/core/common.yml :
328- https://github.com/oneapi-src/unified-runtime /blob/main /scripts/core/common.yml
242+ https://github.com/intel/llvm /blob/sycl/unified-runtime /scripts/core/common.yml
329243.. _scripts/core/enqueue.yml :
330- https://github.com/oneapi-src/unified-runtime /blob/main /scripts/core/enqueue.yml
244+ https://github.com/intel/llvm /blob/sycl/unified-runtime /scripts/core/enqueue.yml
331245.. _scripts/core/loader.yml :
332- https://github.com/oneapi-src/unified-runtime /blob/main /scripts/core/loader.yml
246+ https://github.com/intel/llvm /blob/sycl/unified-runtime /scripts/core/loader.yml
333247.. _scripts/core/registry.yml :
334- https://github.com/oneapi-src/unified-runtime /blob/main /scripts/core/registry.yml
248+ https://github.com/intel/llvm /blob/sycl/unified-runtime /scripts/core/registry.yml
335249
336250Core Optional Features
337251----------------------
@@ -367,45 +281,6 @@ the following command from the build directory.
367281
368282 ctest -L "conformance"
369283
370-
371- -----------------------
372-
373- At the moment, not all tests currently pass with all adapters. Some tests are
374- selectively marked as failing on certain adapters using a .match file located
375- at ``test/conformance/<component>/<component>_adapter_<adapter>.match ``. If
376- that file exists, then it must contain a list of test specifiers which
377- specify tests that fail for the given adapter.
378-
379- when run through ``ctest ``, each failing test will be ran in a separate
380- invocation (to capture any crashes) to verify that they are still failing. All
381- tests not matched by the filters will also be ran in a single invocation which
382- must succeed.
383-
384- This behaviour can be disabled by setting the environment variable
385- ``GTEST_OUTPUT ``. If this is set, the test runner assumes it is being ran to
386- collect testing statistics, and just runs the test suite with no filters.
387-
388- The format of the match files are as follows:
389-
390- * Each line consists of the name of a test as understood by gtest. This is the
391- name printed next to ``[ RUN ] `` in the test log.
392- * ``* `` is a wildcard that matches any number of characters in a test name. ``? ``
393- matches a single character.
394- * Empty lines or lines beginning with ``# `` are ignored.
395- * A line beginning with ``{{OPT}} `` is a optional test; see below.
396-
397- Normally tests in the match file must fail (either by crashing or having a test
398- failure) for the given adapter. However this can be disabled by prepending
399- ``{{OPT}} `` to the match line. This can be used if the test is flaky or
400- depends on a particular environment.
401-
402- This matching is done via ``test/conformance/cts_exe.py ``, which is designed to be
403- called from ctest. However, it can be run manually as follows:
404-
405- .. code-block :: console
406-
407- test/conformance/cts_exe.py --test_command build/bin/test-adapter --failslist test/conformance/adapter/adapter_adapter_mytarget.match -- --backend=BACKEND
408-
409284
410285=====================
411286
0 commit comments