-
Notifications
You must be signed in to change notification settings - Fork 125
Add CI testing for builds with multiple adapters #2081
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Could it be an entirely new job that does two test runs, one for each adapter? |
@martygrant I could do that, but I'm concerned about how long the job will take to run. Once I have something working I'll have a look at how long it takes. |
Just keep in mind that not all systems have CUDA and HIP installed, and keeping the versions of those things up-to-date might be annoying. I think one simple solution here would be to use The builds always have at least two adapters since the mock adapter is built unconditionally. |
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
This expands our CI to test the loader; the dispatcher that is used when multiple adapters are availabe. The old "run on hardware" jobs should behave the same (they have the loader tests disabled), but there are new "combined" jobs with OpenCL/Level Zero + Native CPU. Closes: oneapi-src#2081
Currently, we run a single build per adapter (e.g. one build for OpenCL, one build for Level Zero, etc.), which can miss failures in the multi-adapter dispatcher, ur_ldrddi.cpp (e.g. #2048 ).
We should add a CI workflow for the Build & Test HW and e2e jobs that use a build that has multiple adapters enabled (although it can use only one adapter for the test).
The text was updated successfully, but these errors were encountered: