Skip to content
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

Remove old umf leftovers #2214

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

lukaszstolarczuk
Copy link
Contributor

  • pool tracking in UMF is enabled by default,
  • umf label is no longer used in UR's tests.

Pool tracking is enabled in UMF by default since:
oneapi-src/unified-memory-framework#485
This label is not used in tests anymore.
@lukaszstolarczuk lukaszstolarczuk requested review from a team as code owners October 17, 2024 08:53
@github-actions github-actions bot added ci/cd Continuous integration/devliery cuda CUDA adapter specific issues hip HIP adapter specific issues labels Oct 17, 2024
@lukaszstolarczuk
Copy link
Contributor Author

lukaszstolarczuk commented Oct 22, 2024

@oneapi-src/unified-runtime-cuda-write, @oneapi-src/unified-runtime-hip-write, @GeorgeWeb - pls review

@@ -385,8 +385,6 @@ UR_APIEXPORT ur_result_t UR_APICALL urUSMPoolCreate(
///< ::ur_usm_pool_limits_desc_t
ur_usm_pool_handle_t *Pool ///< [out] pointer to USM memory pool
) {
// Without pool tracking we can't free pool allocations.
#ifdef UMF_ENABLE_POOL_TRACKING
Copy link
Contributor

@frasercrmck frasercrmck Oct 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last time I checked, UMF_ENABLE_POOL_TRACKING was disabled in HIP (note the lack of CMake adding the compile definitions). Has something changed such that we're able to enable pool tracking by default in HIP?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

och, I've missed that, thanks for the review! On the other hand, the CI is green... so either we have some magic in testing or it works as expected... let me verify that further

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forget what the specific problem was, but IIRC only some versions of HIP were having problems. See #1479 and #1689. I couldn't make much progress with it just ended up prioritising something else, but I see in my notes that I put it down to HIP 5.7.1 crashing in CI (at the time) whereas locally 6.0+ was okay.

I don't know what we're testing in CI these days, I'm afraid.

Copy link
Contributor

@GeorgeWeb GeorgeWeb Oct 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, we don't run HIP E2E testing for DPC++, so I wonder if that's something we ought to verify too tho unlikely to happen since it looks like the Precommit CI for that target is not running in intel/llvm atm.
I am unaware what the UMF tracking problems with HIP were and I presume the passing CI, based on Fraser's previous observations, could be due to testing newer version of HIP these days.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've rebased that old PR of mine, just in case it is able to provide some more context/data about what's going on.

Copy link
Contributor

@GeorgeWeb GeorgeWeb Oct 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @lukaszstolarczuk
This PR #1689 removes some more USMAlloc tests from the match files and they seem to fail with enabled memory pools (via UMF_ENABLE_POOL_TRACKING). Maybe they should remain as known failures for now and we still have memory pools enabled by default but I am not sure of any implications.
I think I'll use yours and @frasercrmck's best judgement on this matter.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think, given that this PR is not NFC for HIP, we should see some changes to the match files. The PR description should also reflect this. If there are still failures in the USM tests with this PR (as I suspect there will be, given the problems I had on my PR) then we need to account for them somehow. This might be tricky given that CI isn't currently testing a supported GPU.

@GeorgeWeb
Copy link
Contributor

GeorgeWeb commented Oct 28, 2024

Should we be adding a counterpart intel/llvm PR that tests the latest state of the runtime and bumps the UR tag accordingly too?

@martygrant
Copy link
Contributor

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-close ci/cd Continuous integration/devliery cuda CUDA adapter specific issues hip HIP adapter specific issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants