[UR][L0] Propagate errors from USMAllocationMakeResident

[0x12CC]

This change ensures that USM allocation APIs don't return UR_RESULT_SUCCESS when an error occurs within USMAllocationMakeResident.

[0x12CC]

This PR was originally created here: intel/llvm#11312.

[jandres742]

Please open draft PR in intel/llvm for pre-merge testing, as indicated here https://github.com/oneapi-src/unified-runtime/pull/902/files

[jandres742]

changes are looking good, we just need to have the pre-merge testing.

[0x12CC]

Please open draft PR in intel/llvm for pre-merge testing, as indicated here https://github.com/oneapi-src/unified-runtime/pull/902/files

I've already opened intel/llvm#11312 and it passed all testing. There are no other changes needed in intel/llvm. What's the motivation to create a 3rd PR?

[jandres742]

Please open draft PR in intel/llvm for pre-merge testing, as indicated here https://github.com/oneapi-src/unified-runtime/pull/902/files

I've already opened intel/llvm#11312 and it passed all testing. There are no other changes needed in intel/llvm. What's the motivation to create a 3rd PR?

From https://github.com/oneapi-src/unified-runtime/pull/902/files:

7. Once the oneapi-src/unified-runtime pull request is accepted:

• Reverse the change to UNIFIED_RUNTIME_REPO_ made in step 2.
• Update the UNIFIED_RUNTIME_TAG_ to point at the
  oneapi-src/unified-runtime commit/tag containing the merged adapter
  changes.
• Mark the intel/llvm pull request as ready for review and follow their
  review process.

so basically, we want a draft PR that we can use for pre-merge testing (which is what you prev PR was doing), and then, to pull down the changes (that's the part missing). See example here https://github.com/intel/llvm/pull/11336/files

Sorry for that. We are just trying to come up with this new flow to ensure we maintain quality in all UR merges with respect to SYCL.

[0x12CC]

Thanks for the explanation, @jandres742! I've made the following changes:

• Switched [UR][L0] Propagate errors from USMAllocationMakeResident intel/llvm#11312 to a draft.
• Updated the UNIFIED_RUNTIME_REPO and UNIFIED_RUNTIME_TAG to this branch.
• Removed any other code changes since they're not needed anymore.

I'm not sure I understand the purpose of the last step in your process. After this PR is merged, won't my changes be added to SYCL during the next UR update? Is your intent with this process to have SYCL always use the latest commit in adapters rather than the latest stable release?

[jandres742]

thanks @0x12CC

won't my changes be added to SYCL during the next UR update? Is your intent with this process to have SYCL always use the latest commit in adapters rather than the latest stable release?

I would say intent is the latter, as the only way to know that the code we are merging in the adapters branch is stable by having it in intel/llvm as up-to-date as possible.

@kbenzie : what do you think?

[kbenzie]

thanks @0x12CC

won't my changes be added to SYCL during the next UR update? Is your intent with this process to have SYCL always use the latest commit in adapters rather than the latest stable release?

I would say intent is the latter, as the only way to know that the code we are merging in the adapters branch is stable by having it in intel/llvm as up-to-date as possible.

@kbenzie : what do you think?

There is no automated update process in intel/llvm to use the weekly stable tags. As such, keeping intel/llvm as up-to-date as possible is the goal here. Having a 1:1 UR to intel/llvm relationship for changes made the most sence, at least in the short term. That way we can hopefully avoid "omnibus PRs" that address multiple unrelated UR or intel/llvm changes at once.

This is a very new and rushed process. We'll be looking to streamline it moving forwards where possible while seeking to retaining quality/testing standards.

[AlexeySachkov]

@jandres742, are there any additional comments/requests about this PR which prevent it from being merged?

[jandres742]

@jandres742, are there any additional comments/requests about this PR which prevent it from being merged?

nothing else from my side, approved, thanks @0x12CC !

[jandres742]

Checks on intel/llvm PR are good intel/llvm#11312