Skip to content

[ExecuTorch][Weight Sharing][XNNPACK] load named data map data for xnnpack #9152

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

Merged
merged 5 commits into from
Mar 14, 2025

Conversation

mcr229
Copy link
Contributor

@mcr229 mcr229 commented Mar 11, 2025

Stack from ghstack (oldest at bottom):

If data is serialized into the NamedDataMap, then we overload getConstantDataPtr to retrieve the data from the named data map. This should be done in a Backwards Compatible way. Meaning if no data is serialized into the named data map, then we are still loading the data from the flatbuffer payload.

Since the runtime change here is being made before the AoT changes, All CI on this diff by itself should test that the changes made here are backwards compatitble.

Note: We do not resolve Runtime Memory usage at this point. WeightCache will be implemented in the next diff. Meaning If we load via the same key across different methods, we still pack twice and allocate two instances for the packed weights.

Differential Revision: D70315209

…npack

If data is serialized into the NamedDataMap, then we overload getConstantDataPtr to retrieve the data from the named data map. This should be done in a Backwards Compatible way. Meaning if no data is serialized into the named data map, then we are still loading the data from the flatbuffer payload.

Since the runtime change here is being made before the AoT changes, All CI on this diff by itself should test that the changes made here are backwards compatitble.

Note: We do not resolve Runtime Memory usage at this point. WeightCache will be implemented in the next diff. Meaning If we load via the same key across different methods, we still pack twice and allocate two instances for the packed weights.

Differential Revision: [D70315209](https://our.internmc.facebook.com/intern/diff/D70315209/)

[ghstack-poisoned]
@mcr229 mcr229 requested a review from digantdesai as a code owner March 11, 2025 19:54
Copy link

pytorch-bot bot commented Mar 11, 2025

🔗 Helpful Links

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

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

✅ No Failures

As of commit 935f105 with merge base 630d0cc (image):
💚 Looks good so far! There are no failures yet. 💚

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

@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D70315209

…data for xnnpack"

If data is serialized into the NamedDataMap, then we overload getConstantDataPtr to retrieve the data from the named data map. This should be done in a Backwards Compatible way. Meaning if no data is serialized into the named data map, then we are still loading the data from the flatbuffer payload.

Since the runtime change here is being made before the AoT changes, All CI on this diff by itself should test that the changes made here are backwards compatitble.

Note: We do not resolve Runtime Memory usage at this point. WeightCache will be implemented in the next diff. Meaning If we load via the same key across different methods, we still pack twice and allocate two instances for the packed weights.

Differential Revision: [D70315209](https://our.internmc.facebook.com/intern/diff/D70315209/)

[ghstack-poisoned]
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D70315209

@mcr229 mcr229 added the release notes: xnnpack Changes to the XNNPack backend delegate label Mar 11, 2025
…data for xnnpack"

If data is serialized into the NamedDataMap, then we overload getConstantDataPtr to retrieve the data from the named data map. This should be done in a Backwards Compatible way. Meaning if no data is serialized into the named data map, then we are still loading the data from the flatbuffer payload.

Since the runtime change here is being made before the AoT changes, All CI on this diff by itself should test that the changes made here are backwards compatitble.

Note: We do not resolve Runtime Memory usage at this point. WeightCache will be implemented in the next diff. Meaning If we load via the same key across different methods, we still pack twice and allocate two instances for the packed weights.

Differential Revision: [D70315209](https://our.internmc.facebook.com/intern/diff/D70315209/)

[ghstack-poisoned]
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D70315209

…data for xnnpack"

If data is serialized into the NamedDataMap, then we overload getConstantDataPtr to retrieve the data from the named data map. This should be done in a Backwards Compatible way. Meaning if no data is serialized into the named data map, then we are still loading the data from the flatbuffer payload.

Since the runtime change here is being made before the AoT changes, All CI on this diff by itself should test that the changes made here are backwards compatitble.

Note: We do not resolve Runtime Memory usage at this point. WeightCache will be implemented in the next diff. Meaning If we load via the same key across different methods, we still pack twice and allocate two instances for the packed weights.

Differential Revision: [D70315209](https://our.internmc.facebook.com/intern/diff/D70315209/)

[ghstack-poisoned]
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D70315209

…data for xnnpack"

If data is serialized into the NamedDataMap, then we overload getConstantDataPtr to retrieve the data from the named data map. This should be done in a Backwards Compatible way. Meaning if no data is serialized into the named data map, then we are still loading the data from the flatbuffer payload.

Since the runtime change here is being made before the AoT changes, All CI on this diff by itself should test that the changes made here are backwards compatitble.

Note: We do not resolve Runtime Memory usage at this point. WeightCache will be implemented in the next diff. Meaning If we load via the same key across different methods, we still pack twice and allocate two instances for the packed weights.

Differential Revision: [D70315209](https://our.internmc.facebook.com/intern/diff/D70315209/)

[ghstack-poisoned]
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D70315209

@facebook-github-bot facebook-github-bot merged commit 64ec24d into gh/mcr229/8/base Mar 14, 2025
76 of 78 checks passed
@facebook-github-bot facebook-github-bot deleted the gh/mcr229/8/head branch March 14, 2025 21:26
SS-JIA pushed a commit that referenced this pull request Mar 15, 2025
…npack (#9294)

This PR was created by the merge bot to help merge the original PR into
the main branch.
ghstack PR number: #9152 by
@mcr229
^ Please use this as the source of truth for the PR details, comments,
and reviews
ghstack PR base:
https://github.com/pytorch/executorch/tree/gh/mcr229/8/base
ghstack PR head:
https://github.com/pytorch/executorch/tree/gh/mcr229/8/head
Merge bot PR base:
https://github.com/pytorch/executorch/tree/gh/mcr229/7/orig
Merge bot PR head:
https://github.com/pytorch/executorch/tree/gh/mcr229/8/orig
@diff-train-skip-merge

---------

Co-authored-by: Max Ren <maxren@meta.com>
SS-JIA pushed a commit that referenced this pull request Mar 15, 2025
…npack

Pull Request resolved: #9152

If data is serialized into the NamedDataMap, then we overload getConstantDataPtr to retrieve the data from the named data map. This should be done in a Backwards Compatible way. Meaning if no data is serialized into the named data map, then we are still loading the data from the flatbuffer payload.

Since the runtime change here is being made before the AoT changes, All CI on this diff by itself should test that the changes made here are backwards compatitble.

Note: We do not resolve Runtime Memory usage at this point. WeightCache will be implemented in the next diff. Meaning If we load via the same key across different methods, we still pack twice and allocate two instances for the packed weights.
ghstack-source-id: 271732048
@exported-using-ghexport

Differential Revision: [D70315209](https://our.internmc.facebook.com/intern/diff/D70315209/)
DannyYuyang-quic pushed a commit to CodeLinaro/executorch that referenced this pull request Apr 2, 2025
…npack (pytorch#9294)

This PR was created by the merge bot to help merge the original PR into
the main branch.
ghstack PR number: pytorch#9152 by
@mcr229
^ Please use this as the source of truth for the PR details, comments,
and reviews
ghstack PR base:
https://github.com/pytorch/executorch/tree/gh/mcr229/8/base
ghstack PR head:
https://github.com/pytorch/executorch/tree/gh/mcr229/8/head
Merge bot PR base:
https://github.com/pytorch/executorch/tree/gh/mcr229/7/orig
Merge bot PR head:
https://github.com/pytorch/executorch/tree/gh/mcr229/8/orig
@diff-train-skip-merge

---------

Co-authored-by: Max Ren <maxren@meta.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. fb-exported release notes: xnnpack Changes to the XNNPack backend delegate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants