-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Add generic support for Intel Gaudi accelerator (hpu device) #11328
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
Open
dsocek
wants to merge
5
commits into
huggingface:main
Choose a base branch
from
dsocek:hpu_support
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 4 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
2c6a028
Add generic support for Intel Gaudi accelerator (hpu device)
dsocek fd2e7bf
Merge branch 'main' into hpu_support
sayakpaul ae3c497
Add loggers for generic HPU support
dsocek baf75db
Refactor hpu support with is_hpu_available() logic
dsocek 04f2f55
Fix style for hpu support update
dsocek File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we keep the
device_type
check that was here earlier? e.g. If HPU is available on the machine, and we setpipe.to(torch.float16)
this path would still run and set the device silently right?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DN6 with the new
is_hpu_available()
we dont need explicit device check. Device will silently be set tohpu
withinis_hpu_available()
when all checks for HPU env passThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ohh this would not be expected by our users and not aligned with our design philosophy: they would need to explicitly set
device_type
if they want to use the non-default oneThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If
habana_frameworks
is hooked into torch, then HPU would be the default deviceThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dsocek So if I understand correctly, if an HPU is available and the pipeline needs to be run on CPU it wont unless it's explicitly moved?
Assuming the following snippet runs on an HPU machine
e.g
To run on CPU you would have to explicitly set
pipe.to(cpu)
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DN6 @yiyixuxu
Apologies for the earlier confusion - my previous comment was incorrect. 🙇
I was referring to the if statement in the
to()
function of this PR where I originally usedif device == "hpu"
, and after refactoring now useis_hpu_available()
. We don't explicitly have "hpu" check anymore in the if statement.This new check will not change any user expected behavior:
Current PR's behavior is as follows:
pipe.to()
not called: then device used will be (default) CPUpipe.to("cpu")
: then device used will be CPUpipe.to("hpu")
: then device used will be HPUHere we 1st check is if "habana_frameworks" or "habana_frameworks.torch" are in the environment.
If they are, then we set hpu_migration RT var to true, and import habana_frameworks.torch.
We must define this run-time var before importing
habana_frameworks.torch
.All of this will still keep device on CPU unless user explicitly set it to HPU
Finally we also do hard checks hasattr(torch, "hpu") and torch.hpu.is_available()
Let me know if further adjustments are needed :)