🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• Run pull request jobs on OSDC runners in shadow mode

❌ 19 New Failures, 2 Unrelated Failures

As of commit 2279790 with merge base a4bd823 ():

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

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

@winskuo-quic can you give a bit of context when and why this was introduced, why are we thinking to deprecate, i understand that we need to customize the runner per version and model, but i like the idea of something readily available for our users to get started, may be we can think about the optimum-et (qnn recipe) approach?

@winskuo-quic can you give a bit of context when and why this was introduced, why are we thinking to deprecate, i understand that we need to customize the runner per version and model, but i like the idea of something readily available for our users to get started, may be we can think about the optimum-et (qnn recipe) approach?

Hi @abhinaykukkadapu,
I totally agree it is great to have something readily available for users to get started. For this reason we are just removing parts of the aihub logic and not all.
We kept the logic under backends/qualcom/ that is aihub related in case we need more aihub model support in future. However, these scripts under examples/qualcomm that I'm removing in this PR is mainly due to bc issues and I believe this is now confusing users rather than helping users. There had been couple issues reported recently about unable to run aihub models with our scripts. Please let me know if you think this makes sense and would appreciate if you could share more about how aihub works with optimum-et (qnn recipe) approach.

Also, I have a question related to the gh stack and how it works with open-source project. Could you share some of your experience? Thanks
Link: #19143 (comment)

@winskuo-quic can you give a bit of context when and why this was introduced, why are we thinking to deprecate, i understand that we need to customize the runner per version and model, but i like the idea of something readily available for our users to get started, may be we can think about the optimum-et (qnn recipe) approach?

Hi @abhinaykukkadapu, I totally agree it is great to have something readily available for users to get started. For this reason we are just removing parts of the aihub logic and not all. We kept the logic under backends/qualcom/ that is aihub related in case we need more aihub model support in future. However, these scripts under examples/qualcomm that I'm removing in this PR is mainly due to bc issues and I believe this is now confusing users rather than helping users. There had been couple issues reported recently about unable to run aihub models with our scripts. Please let me know if you think this makes sense and would appreciate if you could share more about how aihub works with optimum-et (qnn recipe) approach.

Also, I have a question related to the gh stack and how it works with open-source project. Could you share some of your experience? Thanks Link: #19143 (comment)

Thanks for trying it out, i didn't know you have to go through codelinaro, as it is internal to qcom i'm not sure if it works with stacked PRs. Not sure which ghstack tool, you've tried but there are two:

1. from native github, this would be best if you directly work through gh locally and not through gerrit. But i doubt you will: https://github.com/github/gh-stack
2. A tool from Ed (PyTorch): https://github.com/ezyang/ghstack

The fundamental problem is that, for stacked PRs that depends on one other the "base" of the first PR will be "main" and subsequent PRs merge base would be previous ones. For example:

For PR2: PR1 (base) <- PR2
For PR1: main (base) <- PR1

So in general, we would merge starting from PR1 since its base is main, subsequent merges its base automatically updated to main once the PR1 is merged.

Please let me know if you think this makes sense and would appreciate if you could share more about how aihub works with optimum-et (qnn recipe) approach.

Ohh sorry, i think i mixed it up, i meant something like this in huggingface, but not sure if QCOM has something like this in hf: https://huggingface.co/Abhinayk