[UR][CI] Add first version of UR workflow #16827

lukaszstolarczuk · 2025-01-29T12:04:18Z

~~Last commit included just to verify if test_job will be executed.~~

With extra dummy changes (now missing in PR) we just didn't skip the test_job, e.g. here: https://github.com/intel/llvm/actions/runs/13040807649/job/36382037543

.github/workflows/sycl-linux-precommit.yml

.github/workflows/ur-build-hw.yml

kbenzie · 2025-01-29T14:21:38Z

sycl/cmake/modules/UnifiedRuntimeTag.cmake

+# Date:   Wed Jan 22 11:06:11 2025 +0100
+# [common] Bump UMF to early 0.11 version, from main
+# It includes i.a. MacOS fix for compiler.
+set(UNIFIED_RUNTIME_TAG d193046de592482c47d87fdfaf92c7b8c59c9b66)


Is this tag update necessary for the workflow changes?

just a dummy change to trigger sycl changes (in detect_changes job) - replaced now with dummy changes for unified-runtime dir - this commit will be removed before merging, of course

.github/workflows/unified-runtime.yml

kbenzie · 2025-02-04T16:39:50Z

During the meeting we think that we should merge this before the PR which pulls in the UR source code once we have the jobs working correctly. Then, in the time between merging this and pulling in the UR sources we disable the workflow to avoid overloading the runners.

lukaszstolarczuk · 2025-02-07T14:35:17Z

So, FYI, the current status is that the CUDA runner went wild, not sure what happened (I'm betting a bad apt update). Working on reviving the machine, if nothing succeed I'll replace it with a different runner...

lukaszstolarczuk · 2025-02-13T08:02:09Z

there's new CUDA runner enabled, we should be good now.

kbenzie · 2025-02-13T15:31:40Z

Failures are known flaky:

kbenzie · 2025-02-13T15:32:31Z

@intel/dpcpp-devops-reviewers please review

sarnex

first pass!

sarnex · 2025-02-13T15:06:47Z

.github/workflows/ur-build-hw.yml

@@ -0,0 +1,132 @@
+name: UR - Build adapters on HW


maybe a nit, but what does it mean to build an adapter on hardware?

In this case it means run the tests on hardware, these jobs don't currently have a build/test separation. The name can be updated:

Suggested change

name: UR - Build adapters on HW

name: UR - Build adapters, test on HW

sarnex · 2025-02-13T15:09:15Z

.github/workflows/ur-build-hw.yml

+
+    - name: Download DPC++
+      run: |
+        wget -O ${{github.workspace}}/dpcpp_compiler.tar.gz https://github.com/intel/llvm/releases/download/nightly-2024-12-12/sycl_linux.tar.gz


do we want to use the same dpcpp version every time or do we want to use the latest nightly

also we could use a docker image that has it preinstalled

Moving forwards we should definitely use the nightly. We had issues in the past which is why these jobs use a fixed version for now.

I think, for the same of ensuring as smooth a transition as possible, we should leave this fixed version and work on use the nightly post merge.

The work on enable use of docker images on these runners is ongoing.

I've updated the TODO list, for after the move.

sarnex · 2025-02-13T15:27:35Z

.github/workflows/ur-build-hw.yml

+        -DUR_DPCXX=${{github.workspace}}/dpcpp_compiler/bin/clang++
+        -DUR_SYCL_LIBRARY_DIR=${{github.workspace}}/dpcpp_compiler/lib
+        -DCMAKE_INSTALL_PREFIX=${{github.workspace}}/install
+        ${{ matrix.adapter.name == 'HIP' && '-DUR_CONFORMANCE_AMD_ARCH=gfx1030' || '' }}


im not sure i understand why we need to set DUR_CONFORMANCE_AMD_ARCH here

This might be a hang over, I think we autodetect the AMD GPU arch for compiling test programs for the device now.

sarnex · 2025-02-13T15:28:31Z

.github/workflows/ur-build-hw.yml

+
+    - name: Build
+      # This is so that device binaries can find the sycl runtime library
+      run: cmake --build ${{github.workspace}}/build -j $(nproc)


if you use ninja instead of make as the cmake generator at the configure step (-GNinja) you shouldnt need this, and i think ninja is just better anyway

I agree Ninja generator is better, we have had issues with Unix Makefiles becomeing broken due to not being tested so the CI is ensuring that didn't make its way downstream.

soo... I'm not sure, should we leave it as-is and add extra Ninja job...?

sarnex · 2025-02-13T15:29:47Z

.github/workflows/ur-build-hw.yml

+
+    - name: Test adapter specific
+      working-directory: ${{github.workspace}}/build
+      run: ctest -C ${{matrix.build_type}} --output-on-failure -L "adapter-specific" -E "memcheck" --timeout 600


do we have to set the wd or can we just specify the path when running the tests?

Looks like we could add the --test-dir ${{github.workspace}}/build option.

We do intend to replae ctest with lit after the repo move so this will be temporary.

sarnex · 2025-02-13T15:30:02Z

.github/workflows/ur-build-hw.yml

+    - name: Get information about platform
+      working-directory: ${{github.workspace}}/unified-runtime
+      if: ${{ always() }}
+      run: .github/scripts/get_system_info.sh


is this just for debugging output?

It has been very helpful for diagnosing job failures, yes.

@sarnex - thoughts? should I remove it?

sarnex · 2025-02-13T15:30:41Z

.github/workflows/ur-build-hw.yml

+    - name: Get information about platform
+      working-directory: ${{github.workspace}}/unified-runtime
+      if: ${{ always() }}
+      run: .github/scripts/get_system_info.sh


i dont think this file exists

This is in the UR repo https://github.com/oneapi-src/unified-runtime/blob/main/.github/scripts/get_system_info.sh, its found because of the working-directory line pointing to the UR clone which exists in the same location as it will post repo move.

sarnex · 2025-02-13T15:31:45Z

.github/workflows/ur-precommit.yml

+  # - test_job should be removed
+  #
+  test_job:
+    name: UR test job


should we instead say Detect UR changes?

nope, this is a test_job which is here just to show how the if should be used. As stated in the TODO comment above - after moving UR here it should be removed. Added comment.

sarnex · 2025-02-13T15:32:18Z

.github/workflows/ur-precommit.yml

+      adapter_name: L0_V2
+      runner_name: UR_L0
+
+  level_zero_static:


we could use a matrix for all of the adapters

We used this approach to separate adapters jobs from each other. Meaning, if any adapter failed, all other could still be tested out. I think it was added like that some time ago, because some adapters were less stable than the others.
I think we can change it to matrix now. Done.

strategy: fail-fast: false matrix: include:

? That's what we use in E2E tasks.

sarnex · 2025-02-13T15:33:25Z

.github/workflows/ur-source-checks.yml

+        Expand-Archive -Path "$WorkingDir\doxygen.zip"
+        Add-Content $env:GITHUB_PATH "$WorkingDir\doxygen"
+
+    - name: "[Lin] Install hwloc"


imo we should split the win/lin steps into seperate workflows

I'm willing to have them in a single file for now. The benefits for SYCL were:

Ability to cancel individual Linux/Windows if some CI job isn't necessary

Job dispatch control via "Environment" for when we had zombie processes post testing making the runner unusable for subsequent tasks.

If UR CI won't be affected by these (I'd assume it won't), then there will be little value in splitting the OSes.

yeah my comment was mainly about confusion reading the results because people are used to how it's done for sycl, but its not a big deal

added to the TODO list

aelovikov-intel · 2025-02-13T15:27:06Z

.github/workflows/ur-build-hw.yml

+name: UR - Build adapters on HW
+
+on:
+  workflow_call:


We prefer helper workflows like this one to have an additional workflow_dispatch trigger for testing/experimenting, e.g.

llvm/.github/workflows/sycl-linux-run-tests.yml

Line 106 in 822cf9b

workflow_dispatch:

aelovikov-intel · 2025-02-13T15:29:00Z

.github/workflows/ur-build-hw.yml

+    # Also, the step of downloading DPC++ should be integrated somehow;
+    # either compile it or use cached binaries (if accessible)...?


Nightly "release" maybe? We don't try re-use post-commit binaries (although artifacts might actually be available).

Nightly would make sense, yeah. A related comment here.

aelovikov-intel · 2025-02-13T15:30:51Z

.github/workflows/ur-build-hw.yml

+
+    - name: Configure CMake
+      working-directory: ${{github.workspace}}/unified-runtime
+      run: >


Suggested change

run: >

run: |

or a comment why different from other steps/workflows.

aelovikov-intel · 2025-02-13T15:32:12Z

.github/workflows/ur-build-hw.yml

+
+    - name: Build
+      # This is so that device binaries can find the sycl runtime library
+      run: cmake --build ${{github.workspace}}/build -j $(nproc)


Can we just use ninja instead of make as generator and then

Suggested change

run: cmake --build ${{github.workspace}}/build -j $(nproc)

run: cmake --build ${{github.workspace}}/build

aelovikov-intel · 2025-02-13T15:35:01Z

.github/workflows/ur-precommit.yml

+  level_zero:
+    name: Level Zero
+    needs: [source_checks]
+    uses: ./.github/workflows/ur-build-hw.yml
+    with:
+      adapter_name: L0
+      runner_name: UR_L0
+
+  level_zero_v2:
+    name: Level Zero V2
+    needs: [source_checks]
+    uses: ./.github/workflows/ur-build-hw.yml
+    with:
+      adapter_name: L0_V2
+      runner_name: UR_L0
+
+  level_zero_static:
+    name: Level Zero static
+    needs: [source_checks]
+    uses: ./.github/workflows/ur-build-hw.yml
+    with:
+      adapter_name: L0
+      runner_name: UR_L0
+      static_loader: ON
+      static_adapter: ON
+
+  opencl:
+    name: OpenCL
+    needs: [source_checks]
+    uses: ./.github/workflows/ur-build-hw.yml
+    with:
+      adapter_name: OPENCL
+      runner_name: UR_OPENCL
+      platform: "Intel(R) OpenCL"


Why isn't this a matrix?

Use custom runner names - UR_*

lukaszstolarczuk had a problem deploying to WindowsCILock January 29, 2025 12:06 — with GitHub Actions Failure

lukaszstolarczuk had a problem deploying to WindowsCILock January 29, 2025 12:38 — with GitHub Actions Failure

lukaszstolarczuk had a problem deploying to WindowsCILock January 29, 2025 12:54 — with GitHub Actions Failure

lukaszstolarczuk force-pushed the ur-first-workflows branch from f61518c to 7762529 Compare January 29, 2025 13:04

lukaszstolarczuk had a problem deploying to WindowsCILock January 29, 2025 13:04 — with GitHub Actions Failure

kbenzie reviewed Jan 29, 2025

View reviewed changes

lukaszstolarczuk force-pushed the ur-first-workflows branch from 7762529 to f9cecd5 Compare January 29, 2025 21:04

lukaszstolarczuk had a problem deploying to WindowsCILock January 29, 2025 21:04 — with GitHub Actions Error

lukaszstolarczuk force-pushed the ur-first-workflows branch from f9cecd5 to 9a36d44 Compare January 29, 2025 21:08

lukaszstolarczuk temporarily deployed to WindowsCILock January 29, 2025 21:09 — with GitHub Actions Inactive

lukaszstolarczuk had a problem deploying to WindowsCILock January 29, 2025 21:23 — with GitHub Actions Error

lukaszstolarczuk temporarily deployed to WindowsCILock January 29, 2025 21:30 — with GitHub Actions Inactive

lukaszstolarczuk temporarily deployed to WindowsCILock January 29, 2025 21:45 — with GitHub Actions Inactive

lukaszstolarczuk force-pushed the ur-first-workflows branch from ba4ea20 to d85dd23 Compare February 3, 2025 15:19

lukaszstolarczuk temporarily deployed to WindowsCILock February 3, 2025 15:19 — with GitHub Actions Inactive

lukaszstolarczuk temporarily deployed to WindowsCILock February 3, 2025 15:36 — with GitHub Actions Inactive

lukaszstolarczuk force-pushed the ur-first-workflows branch from d85dd23 to 1a68aa0 Compare February 4, 2025 11:49

lukaszstolarczuk temporarily deployed to WindowsCILock February 4, 2025 11:50 — with GitHub Actions Inactive

lukaszstolarczuk temporarily deployed to WindowsCILock February 4, 2025 12:08 — with GitHub Actions Inactive

lukaszstolarczuk force-pushed the ur-first-workflows branch from 1a68aa0 to c45824f Compare February 12, 2025 22:13

lukaszstolarczuk temporarily deployed to WindowsCILock February 12, 2025 22:13 — with GitHub Actions Inactive

lukaszstolarczuk had a problem deploying to WindowsCILock February 12, 2025 22:30 — with GitHub Actions Error

lukaszstolarczuk force-pushed the ur-first-workflows branch from c45824f to 4ac5046 Compare February 12, 2025 22:50

lukaszstolarczuk temporarily deployed to WindowsCILock February 12, 2025 22:52 — with GitHub Actions Inactive

lukaszstolarczuk temporarily deployed to WindowsCILock February 12, 2025 23:12 — with GitHub Actions Inactive

lukaszstolarczuk marked this pull request as ready for review February 13, 2025 08:01

lukaszstolarczuk requested a review from a team as a code owner February 13, 2025 08:01

kbenzie force-pushed the ur-first-workflows branch from 4ac5046 to e0d7e97 Compare February 13, 2025 14:09

kbenzie temporarily deployed to WindowsCILock February 13, 2025 14:09 — with GitHub Actions Inactive

kbenzie temporarily deployed to WindowsCILock February 13, 2025 14:28 — with GitHub Actions Inactive

sarnex reviewed Feb 13, 2025

View reviewed changes

aelovikov-intel reviewed Feb 13, 2025

View reviewed changes

[UR][CI] Add first version of UR workflow

b28c442

Use custom runner names - UR_*

lukaszstolarczuk force-pushed the ur-first-workflows branch from e0d7e97 to b28c442 Compare February 13, 2025 17:21

lukaszstolarczuk requested a deployment to WindowsCILock February 13, 2025 17:23 — with GitHub Actions Queued

	name: UR - Build adapters on HW
	name: UR - Build adapters, test on HW

		# Also, the step of downloading DPC++ should be integrated somehow;
		# either compile it or use cached binaries (if accessible)...?

	run: cmake --build ${{github.workspace}}/build -j $(nproc)
	run: cmake --build ${{github.workspace}}/build

[UR][CI] Add first version of UR workflow #16827

Are you sure you want to change the base?

[UR][CI] Add first version of UR workflow #16827

Conversation

lukaszstolarczuk commented Jan 29, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kbenzie commented Feb 4, 2025

lukaszstolarczuk commented Feb 7, 2025

lukaszstolarczuk commented Feb 13, 2025

kbenzie commented Feb 13, 2025

kbenzie commented Feb 13, 2025

sarnex left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sarnex Feb 13, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lukaszstolarczuk commented Jan 29, 2025 •

edited

Loading

sarnex Feb 13, 2025 •

edited

Loading