[GHA] Uplift Linux GPU RT version to 23.17.26241.22

[bb-sycl]

Scheduled drivers uplift

[bader]

@aelovikov-intel, FYI.

[aelovikov-intel]

@aelovikov-intel, FYI.

I somewhat doubt it's the CI because the testing in #10054 finished successfully. Is it possible the drivers are bad/incompatible?

[bader]

@aelovikov-intel, FYI.

I somewhat doubt it's the CI because the testing in #10054 finished successfully. Is it possible the drivers are bad/incompatible?

From the logs:

Traceback (most recent call last):
  File "/opt/get_release.py", line 19, in <module>
    release = get_release_by_tag(repo, tag)
  File "/opt/get_release.py", line 6, in get_release_by_tag
    release = urlopen("https://api.github.com/repos/" + repo + "/releases/tags/" + tag).read()
  File "/usr/lib/python3.10/urllib/request.py", line 216, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.10/urllib/request.py", line 525, in open
    response = meth(req, response)
  File "/usr/lib/python3.10/urllib/request.py", line 634, in http_response
    response = self.parent.error(
  File "/usr/lib/python3.10/urllib/request.py", line 563, in error
    return self._call_chain(*args)
  File "/usr/lib/python3.10/urllib/request.py", line 496, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.10/urllib/request.py", line 643, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 403: rate limit exceeded

[aelovikov-intel]

Re-run doesn't have that issue.

[bader]

Re-run doesn't have that issue.

Okay, but we should think about preventive cure for urllib.error.HTTPError: HTTP Error 403: rate limit exceeded error. Just let it happen and wait + re-run, doesn't sound like a good solution.

[bader]

Re-run doesn't have that issue.

Okay, but we should think about preventive cure for urllib.error.HTTPError: HTTP Error 403: rate limit exceeded error. Just let it happen and wait + re-run, doesn't sound like a good solution.

FYI: I found a bug report for that issue - #8462.

[dm-vodopyanov]

Post-commit failure:

Unexpectedly Passed Tests (1):
  SYCL :: ESIMD/hardware_dispatch.cpp

For these automated Linux GPU driver updates we could run broader scope of testing on pre-commit step automatically.

[dm-vodopyanov]

Fix: #10132

[aelovikov-intel]

For these automated Linux GPU driver updates we could run broader scope of testing on pre-commit step automatically.

I think that could be as easy as making

llvm/.github/workflows/sycl_precommit.yml

Line 69 in 1bb5648

lts_config: "hip_amdgpu;lin_intel;esimd_emu;cuda_aws;win_l0_gen12"

conditional on files changed (i.e., don't use "fused" lin_intel task and prefer separate l0_gen9, ocl_gen9 and ocl_x64).

Condition could probably be based on contains(needs.detect_changes.outputs.filters, 'drivers_and_configs') - see

llvm/.github/workflows/sycl_detect_changes.yml

Lines 50 to 59 in 1bb5648

	ci:
	- .github/workflows/**
	- devops/*/**
	# devops/* contains config files, including drivers versions.
	# Allow them to be tested in pre-commit.
	drivers_and_configs: &drivers_and_configs
	- devops/*
	test_build:
	- *sycl
	- *drivers_and_configs

.

[bader]

@dm-vodopyanov, @aelovikov-intel, could you clarify what testing is missing in this PR pre-commit? Don't we run ESIMD tests on GPU in all pre-commits?

[aelovikov-intel]

https://github.com/intel/llvm/blob/sycl/sycl/test-e2e/README.md?plain=1#L34-L44

We don't test for XFAIL in pre-commit.

[bader]

https://github.com/intel/llvm/blob/sycl/sycl/test-e2e/README.md?plain=1#L34-L44

We don't test for XFAIL in pre-commit.

This text doesn't say if there is any difference in XFAIL semantics between post- and pre- commits. Why does the test fail in post-commit?

[aelovikov-intel]

Because in pre-commit we run with

llvm/devops/test_configs.json

Line 12 in 042479c

"targets": "ext_oneapi_level_zero:gpu;opencl:gpu;opencl:cpu",

and in post-commit with

llvm/devops/test_configs.json

Line 24 in 042479c

"targets": "ext_oneapi_level_zero:gpu",

[bader]

So just having additional devices in the system changes the status of the test? Do you understand how broken this system is? How are developers supposed to debug issues like this?

[aelovikov-intel]

So just having additional devices in the system changes the status of the test?

No.