Merge changes from multi device compile extension into core spec.

[aarongreig]

We originally changed this interface a bit from PI: currently these entry points take a context which represents your list of devices. This turned out to cause issues for the level zero adapter so the extension was created to effectively revert back to the PI/CL style interface. This PR reverts the core interface back to PI style, everything takes an explicit device list instead of a context.

LLVM testing intel/llvm#12536

[codecov-commenter]

Codecov Report

Attention: 93 lines in your changes are missing coverage. Please review.

Comparison is base (b66cf9b) 15.46% compared to head (46722a5) 15.37%.
Report is 25 commits behind head on main.

Files	Patch %	Lines
source/loader/ur_ldrddi.cpp	0.00%	18 Missing ⚠️
source/loader/layers/validation/ur_valddi.cpp	0.00%	17 Missing ⚠️
test/conformance/program/urProgramLink.cpp	0.00%	17 Missing ⚠️
test/conformance/program/urProgramBuild.cpp	0.00%	9 Missing ⚠️
test/conformance/program/urProgramCompile.cpp	0.00%	9 Missing ⚠️
source/loader/layers/tracing/ur_trcddi.cpp	0.00%	7 Missing ⚠️
source/loader/ur_libapi.cpp	0.00%	4 Missing ⚠️
source/adapters/null/ur_nullddi.cpp	0.00%	3 Missing ⚠️
test/conformance/testing/include/uur/fixtures.h	0.00%	3 Missing ⚠️
test/conformance/kernel/urKernelCreate.cpp	0.00%	1 Missing ⚠️
... and 5 more

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1195      +/-   ##
==========================================
- Coverage   15.46%   15.37%   -0.10%     
==========================================
  Files         238      238              
  Lines       33883    33689     -194     
  Branches     3747     3714      -33     
==========================================
- Hits         5239     5178      -61     
+ Misses      28593    28461     -132     
+ Partials       51       50       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JackAKirk]

Can you add a description for this PR please?
I've looked at e.g. #912 and I think I understand that you want to change the interface so it is more flexible and is associating a particular binary with particular devices.

From my experience of CUDA/HIP Outside of MPI which is a completely different mechanism, I am not aware of any multi-device compilation process where the output of a single compilation is to produce different binaries for each of the device. I don't know of any CUDA/HIP documentation on how to deal with this use case.

Therefore, if you could clarify things like:

• What is the initial motivation for this feature (e.g. give an specific example of a use case that requires such an interface)
• Which backends is this useful for?
• Are there any particular considerations for specific backend?

I think that would help with review, allowing me to make a deeper investigation of any potential backend specific issues. Otherwise the only thing I can check is that it doesn't break the standard case where you are just outputting a single binary for all devices.

[aarongreig]

The extension was a last minute fix for issues level zero ended up having with a redesign, this basically fully reverts the redesign by merging the extension.

[JackAKirk]

The extension was a last minute fix for issues level zero ended up having with a redesign, this basically fully reverts the redesign by merging the extension.

Is there an accompanying PR in intel/llvm to change this line https://github.com/intel/llvm/blob/f4b4a84b653fb77a9db834d4f588ac347681ea30/sycl/plugins/unified_runtime/pi2ur.hpp#L2068
etc?
It would be nice to check such a PR passes intel/llvm CI.

[aarongreig]

..not doing a good job of following my own project's process here

[fabiomestre]

Looks good to me. Also makes things cleaner in OpenCL 👍

[nrspruit]

LGTM for level zero, cleans up things greatly as long as we are not breaking customers that were expecting this behavior.

[PietroGhg]

Native CPU LGTM, thank you

[JackAKirk]

LGTM

[martygrant]

Unified Runtime -> intel/llvm Repo Move Notice

Information

The source code of Unified Runtime has been moved to intel/llvm under the unified-runtime top-level directory,
all future development will now be carried out there. This was done in intel/llvm#17043.

The code will be mirrored to oneapi-src/unified-runtime and the specification will continue to be hosted at oneapi-src.github.io/unified-runtime.

The contribution guide has been updated with new instructions for contributing to Unified Runtime.

PR Migration

All open PRs including this one will be labelled auto-close and shall be automatically closed after 30 days.
To allow for some breathing space, this automation will not be enabled until next week (27/02/2025).

Should you wish to continue with your PR you will need to migrate it to intel/llvm.
We have provided a script to help automate this process.

---

This is an automated comment.

[martygrant]

Unified Runtime -> intel/llvm Repo Move Notice

Following on from the previous notice, we have now enabled workflows to automatically label and close PRs because the Unified Runtime source code has moved to intel/llvm.

This PR has now been marked with the auto-close label and will be automatically closed after 30 days.

Please review the previous notice for more information, including assistance with migrating your PR to intel/llvm.

Should there be a reason for this PR to remain open, manually remove the auto-close label.

---

This is an automated comment.

[github-actions]

Automatic PR Closure Notice

Information

This PR has been closed automatically. It was marked with the auto-close label 30 days ago as part of the Unified Runtime source code migration to the intel/llvm repository - intel/llvm#17043.

All Unified Runtime development should be done in intel/llvm, details can be found in the updated contribution guide.
This repository will continue to exist as a mirror and will host the specification documentation.

Next Steps

Should you wish to re-open this PR it must be moved to intel/llvm. We have provided a script to help automate this process, otherwise no actions are required.

---

This is an automated comment.