🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/145589

• 📄 Preview Python docs built from this PR
• 📄 Preview C++ docs built from this PR
• ❓ Need help or want to give feedback on the CI? Visit the bot commands wiki or our office hours

Note: Links to docs will display an error until the docs builds have been completed.

❌ 12 New Failures

As of commit 0427369 with merge base 9c9b05b ():

This comment was automatically generated by Dr. CI and updates every 15 minutes.

@albanD , @kwen2501 : can you please help with the review and approval , thank you. ( this is lines of the changes introduced in #128584)

It's still quite weird to have this in core given that we don't run this in CI... Sounds fine for me since it's only test but I wouldn't expect this to remain working for any period of time tbh.

cc @malfet in case you have an opinion on this

@albanD : Thanks for your comment, these TCs are disabled by default for other devices (by the existing decorator) so when we want to check them for devices such as Intel Gaudi , we need to do the refactoring or remove the decorators. The change removes this restriction for devices that support the tests and want to run them.

@ankurneog regarding the review: current PR conflicts with trunk and causes 21+ workflow failures....

cc @malfet in case you have an opinion on this

It feels like onlyNativeDeviceType(introduced by #65201 and comment still says it's only CUDA + CPU + Meta, while definition has evolved) served a very specific purpose at times, which seems lost now. IMO all use of this decorator should be replaced (when possible) with skipIfXLA (and probably a few skipIfMPS)

@ankurneog thanks for the details!
I guess the usual way we solve this kind of issues is by providing a generic extension point such that each vendor can customize the logic for their need without requiring their special logic to be in core.
I wonder if it would be possible here as well to have these hpu-specific skip list in your own codebase and pytorch provides only the extension point to make that convenient (if any is needed).

@ankurneog thanks for the details! I guess the usual way we solve this kind of issues is by providing a generic extension point such that each vendor can customize the logic for their need without requiring their special logic to be in core. I wonder if it would be possible here as well to have these hpu-specific skip list in your own codebase and pytorch provides only the extension point to make that convenient (if any is needed).

@albanD : Sure that's doable , in that case can i remove the existing onlyNativeDeviceType decorator for the tests?

cc @malfet in case you have an opinion on this

It feels like onlyNativeDeviceType(introduced by #65201 and comment still says it's only CUDA + CPU + Meta, while definition has evolved) served a very specific purpose at times, which seems lost now. IMO all use of this decorator should be replaced (when possible) with skipIfXLA (and probably a few skipIfMPS)

@malfet : thanks for your comment, then maybe we should remove the onlyNativeDeviceTypes decorator from these tests ?

@ankurneog hanks for your comment, then maybe we should remove the onlyNativeDeviceTypes decorator from these tests ?

If they pass CI, than yes, feels like a right approach

@malfet , @albanD : can you help with the review and approval. Thanks

The committers listed above are authorized under a signed CLA.

• ✅ login: ankurneog / name: Ankur Neog (6e0604b, f574bec, 35ad062, 0427369, 8b4eca5, 0451d84, 5bec8d6)

@pytorchbot rebase

@pytorchbot started a rebase job onto refs/remotes/origin/viable/strict. Check the current status here

Successfully rebased expand_ops_execution onto refs/remotes/origin/viable/strict, please pull locally before adding more changes (for example, via git checkout expand_ops_execution && git pull --rebase)

Looks like this PR hasn't been updated in a while so we're going to go ahead and mark this as Stale.
Feel free to remove the Stale label if you feel this was a mistake.
If you are unable to remove the Stale label please contact a maintainer in order to do so.
If you want the bot to never mark this PR stale again, add the no-stale label.
Stale pull requests will automatically be closed after 30 days of inactivity.