-
Notifications
You must be signed in to change notification settings - Fork 24.2k
has_triton
: Use the device interface for detecting Triton availability
#139171
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
base: main
Are you sure you want to change the base?
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/139171
Note: Links to docs will display an error until the docs builds have been completed. ❌ 2 New Failures, 2 Unrelated FailuresAs of commit d4b2963 with merge base 8904ba6 ( NEW FAILURES - The following jobs have failed:
BROKEN TRUNK - The following job failed but were present on the merge base:👉 Rebase onto the `viable/strict` branch to avoid these failures
UNSTABLE - The following job is marked as unstable, possibly due to flakiness on trunk:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
@pytorchbot label 'topic: not user facing' |
@jansel sorry about that, looks like I messed up the typing, should be ready for another CI run now! |
@pytorchbot merge |
Merge startedYour change will be merged once all checks pass (ETA 0-4 Hours). Learn more about merging in the wiki. Questions? Feedback? Please reach out to the PyTorch DevX Team |
Merge failedReason: 3 mandatory check(s) failed. The first few are:
Dig deeper by viewing the failures on hud |
@jansel @tugsbayasgalan I've fixed the tests and added the HOPs from Inductor that appear when I call |
Hey @jansel, could I trouble you for a re-review please? Thanks! |
Rebased since #152529 was merged. I have removed the changes to the Inductor scheduler checks, I think that is where the problem may lie, instead this only includes the I'm hoping this PR will now pass when workflows are rerun. |
has_triton
: Use the device interface for detecting Triton availability
@pytorchbot merge |
Merge startedYour change will be merged once all checks pass (ETA 0-4 Hours). Learn more about merging in the wiki. Questions? Feedback? Please reach out to the PyTorch DevX Team |
…ity (#139171) Summary: This PR replaces the `has_triton()` global method which was previously used for this task. X-link: pytorch/pytorch#139171 Approved by: https://github.com/jansel, https://github.com/shink Reviewed By: huydhn Differential Revision: D74338720 fbshipit-source-id: 27106df937bbdea2da1f4911ffffcfae056f844d
Looks like this causes a pretty big perf drop on some huggingface models. For example, on an H100 from 2.6x -> 1.3x for the following: |
Hi @masnesral, if this PR is causing those performance drops, it might be because hand-written Triton kernels aren't being used, because from torch.utils._triton import has_triton
print(f"{has_triton()=}")
print(f"{has_triton("cuda")=}")
from torch._dynamo.device_interface import get_interface_for_device
get_interface_for_device("cuda").raise_if_triton_unavailable() # shouldn't throw if all is okay Unfortunately, I don't have access to an H100, but this should work the same. These give Also, to help with debugging this, could you also tell me what the result of these are for you? import triton, torch
print(f'{"nvidia" in triton.backends.backends=}')
print(f'{torch.cuda.get_device_properties("cuda")=}') |
The other thing is, I did change the |
Sorry, gonna try to revert this while we investigate further. |
@pytorchbot revert -m="Performance regression for huggingface" -c=nosignal |
@pytorchbot successfully started a revert job. Check the current status here. |
…vailability (#139171)" This reverts commit 48bfe9a. Reverted #139171 on behalf of https://github.com/masnesral due to Performance regression for huggingface ([comment](#139171 (comment)))
@galexite your PR has been successfully reverted. |
This PR was reopened (likely due to being reverted), so your approval was removed. Please request another review.
@galexite my having tested on H100 doesn't seem to be a related (see links to a100 above), but here's the output you requested anyway. I think it's what you were expecting :/
|
Hmm, okay. I'll have a look! |
…vailability (#139171)" Summary: This reverts commit 48bfe9afc70a98addd5aa738bf501c029e4a9285. Reverted pytorch/pytorch#139171 on behalf of https://github.com/masnesral due to Performance regression for huggingface ([comment](pytorch/pytorch#139171 (comment))) Reviewed By: huydhn Differential Revision: D74531472 fbshipit-source-id: 751398ae3c03cdd1d1d7c75a5088207a3a1784cb
This PR replaces the
has_triton()
global method which was previously used for this task.cc @H-Huang @awgu @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10 @jerryzh168 @voznesenskym @penguinwu @EikanWang @Guobing-Chen @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @chenyang78 @kadeng @muchulee8 @amjames @chauhang @aakhundov @kwen2501 @c-p-i-o @yf225 @ColinPeppler @desertfire @rec