[XNNPACK][Weights Cache] Initial Weights Cache Design with NamedDataMap #9154
Conversation
This file contains 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
XNNWeightsCache Design with NamedDataMap. The intent of the weights cache is for tensors to be loaded (via name) through the named data map.
APIs to be used by XNNCompiler:
- load_unpacked_data
- Takes in a string name (tensor name). The weights cache loads the data for this string from the named data map and returns the pointer. It also creates a mapping of this pointer to the name which is later used by the XNNPACK's internal weight cache implementation
- free_unpacked_data
- Frees all the unpacked data loaded from NamedDataMap. This is only safe to call after xnn_create_runtime has been called. This is because create_runtime takes unpacked data pointers and packs them into a separate buffer.
- a couple getter methods
- get_packed_data_names
- get_unpacked_data_names
- get_num_packed_data
- get() (get's the xnn_weights_cache object)
Internal APIs used by XNNPACK Library
- look_up
- takes a cache key (weight and bias pointers) and looks up the offset to the packed weight if it exists
- look_up_or_insert
- takes a cache key and pointer to packed weights and looks_up the offset if it exists, or inserts a new packed weight into the cache and returns that offset
- offset_to_addr
- gets offset and returns address to packed pointer
- reserve_space
- returns memory address with appropriate sie for XNNPACK to populate with packed weights ( I want to use the runtime_allocator for this but i don't think we have the right sizes, so for now we are just using a string buffer and resizing it)
- is_finalized
- since this cache doesn't necessarily need to care about a finalized state we always return true.
- delete_cache
- deletes cache
Differential Revision: [D70885917](https://our.internmc.facebook.com/intern/diff/D70885917/)
[ghstack-poisoned]
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/9154
Note: Links to docs will display an error until the docs builds have been completed. ❌ 1 New FailureAs of commit b5dc2f4 with merge base 630d0cc ( NEW FAILURE - The following job has failed:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
This was referenced Mar 11, 2025
facebook-github-bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D70885917 |
… NamedDataMap"
XNNWeightsCache Design with NamedDataMap. The intent of the weights cache is for tensors to be loaded (via name) through the named data map.
APIs to be used by XNNCompiler:
- load_unpacked_data
- Takes in a string name (tensor name). The weights cache loads the data for this string from the named data map and returns the pointer. It also creates a mapping of this pointer to the name which is later used by the XNNPACK's internal weight cache implementation
- free_unpacked_data
- Frees all the unpacked data loaded from NamedDataMap. This is only safe to call after xnn_create_runtime has been called. This is because create_runtime takes unpacked data pointers and packs them into a separate buffer.
- a couple getter methods
- get_packed_data_names
- get_unpacked_data_names
- get_num_packed_data
- get() (get's the xnn_weights_cache object)
Internal APIs used by XNNPACK Library
- look_up
- takes a cache key (weight and bias pointers) and looks up the offset to the packed weight if it exists
- look_up_or_insert
- takes a cache key and pointer to packed weights and looks_up the offset if it exists, or inserts a new packed weight into the cache and returns that offset
- offset_to_addr
- gets offset and returns address to packed pointer
- reserve_space
- returns memory address with appropriate sie for XNNPACK to populate with packed weights ( I want to use the runtime_allocator for this but i don't think we have the right sizes, so for now we are just using a string buffer and resizing it)
- is_finalized
- since this cache doesn't necessarily need to care about a finalized state we always return true.
- delete_cache
- deletes cache
Differential Revision: [D70885917](https://our.internmc.facebook.com/intern/diff/D70885917/)
[ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D70885917 |
… NamedDataMap"
XNNWeightsCache Design with NamedDataMap. The intent of the weights cache is for tensors to be loaded (via name) through the named data map.
APIs to be used by XNNCompiler:
- load_unpacked_data
- Takes in a string name (tensor name). The weights cache loads the data for this string from the named data map and returns the pointer. It also creates a mapping of this pointer to the name which is later used by the XNNPACK's internal weight cache implementation
- free_unpacked_data
- Frees all the unpacked data loaded from NamedDataMap. This is only safe to call after xnn_create_runtime has been called. This is because create_runtime takes unpacked data pointers and packs them into a separate buffer.
- a couple getter methods
- get_packed_data_names
- get_unpacked_data_names
- get_num_packed_data
- get() (get's the xnn_weights_cache object)
Internal APIs used by XNNPACK Library
- look_up
- takes a cache key (weight and bias pointers) and looks up the offset to the packed weight if it exists
- look_up_or_insert
- takes a cache key and pointer to packed weights and looks_up the offset if it exists, or inserts a new packed weight into the cache and returns that offset
- offset_to_addr
- gets offset and returns address to packed pointer
- reserve_space
- returns memory address with appropriate sie for XNNPACK to populate with packed weights ( I want to use the runtime_allocator for this but i don't think we have the right sizes, so for now we are just using a string buffer and resizing it)
- is_finalized
- since this cache doesn't necessarily need to care about a finalized state we always return true.
- delete_cache
- deletes cache
Differential Revision: [D70885917](https://our.internmc.facebook.com/intern/diff/D70885917/)
[ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D70885917 |
… NamedDataMap"
XNNWeightsCache Design with NamedDataMap. The intent of the weights cache is for tensors to be loaded (via name) through the named data map.
APIs to be used by XNNCompiler:
- load_unpacked_data
- Takes in a string name (tensor name). The weights cache loads the data for this string from the named data map and returns the pointer. It also creates a mapping of this pointer to the name which is later used by the XNNPACK's internal weight cache implementation
- free_unpacked_data
- Frees all the unpacked data loaded from NamedDataMap. This is only safe to call after xnn_create_runtime has been called. This is because create_runtime takes unpacked data pointers and packs them into a separate buffer.
- a couple getter methods
- get_packed_data_names
- get_unpacked_data_names
- get_num_packed_data
- get() (get's the xnn_weights_cache object)
Internal APIs used by XNNPACK Library
- look_up
- takes a cache key (weight and bias pointers) and looks up the offset to the packed weight if it exists
- look_up_or_insert
- takes a cache key and pointer to packed weights and looks_up the offset if it exists, or inserts a new packed weight into the cache and returns that offset
- offset_to_addr
- gets offset and returns address to packed pointer
- reserve_space
- returns memory address with appropriate sie for XNNPACK to populate with packed weights ( I want to use the runtime_allocator for this but i don't think we have the right sizes, so for now we are just using a string buffer and resizing it)
- is_finalized
- since this cache doesn't necessarily need to care about a finalized state we always return true.
- delete_cache
- deletes cache
Differential Revision: [D70885917](https://our.internmc.facebook.com/intern/diff/D70885917/)
[ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D70885917 |
kirklandsign
approved these changes
Mar 13, 2025
… NamedDataMap"
XNNWeightsCache Design with NamedDataMap. The intent of the weights cache is for tensors to be loaded (via name) through the named data map.
APIs to be used by XNNCompiler:
- load_unpacked_data
- Takes in a string name (tensor name). The weights cache loads the data for this string from the named data map and returns the pointer. It also creates a mapping of this pointer to the name which is later used by the XNNPACK's internal weight cache implementation
- free_unpacked_data
- Frees all the unpacked data loaded from NamedDataMap. This is only safe to call after xnn_create_runtime has been called. This is because create_runtime takes unpacked data pointers and packs them into a separate buffer.
- a couple getter methods
- get_packed_data_names
- get_unpacked_data_names
- get_num_packed_data
- get() (get's the xnn_weights_cache object)
Internal APIs used by XNNPACK Library
- look_up
- takes a cache key (weight and bias pointers) and looks up the offset to the packed weight if it exists
- look_up_or_insert
- takes a cache key and pointer to packed weights and looks_up the offset if it exists, or inserts a new packed weight into the cache and returns that offset
- offset_to_addr
- gets offset and returns address to packed pointer
- reserve_space
- returns memory address with appropriate sie for XNNPACK to populate with packed weights ( I want to use the runtime_allocator for this but i don't think we have the right sizes, so for now we are just using a string buffer and resizing it)
- is_finalized
- since this cache doesn't necessarily need to care about a finalized state we always return true.
- delete_cache
- deletes cache
Differential Revision: [D70885917](https://our.internmc.facebook.com/intern/diff/D70885917/)
[ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D70885917 |
… NamedDataMap"
XNNWeightsCache Design with NamedDataMap. The intent of the weights cache is for tensors to be loaded (via name) through the named data map.
APIs to be used by XNNCompiler:
- load_unpacked_data
- Takes in a string name (tensor name). The weights cache loads the data for this string from the named data map and returns the pointer. It also creates a mapping of this pointer to the name which is later used by the XNNPACK's internal weight cache implementation
- free_unpacked_data
- Frees all the unpacked data loaded from NamedDataMap. This is only safe to call after xnn_create_runtime has been called. This is because create_runtime takes unpacked data pointers and packs them into a separate buffer.
- a couple getter methods
- get_packed_data_names
- get_unpacked_data_names
- get_num_packed_data
- get() (get's the xnn_weights_cache object)
Internal APIs used by XNNPACK Library
- look_up
- takes a cache key (weight and bias pointers) and looks up the offset to the packed weight if it exists
- look_up_or_insert
- takes a cache key and pointer to packed weights and looks_up the offset if it exists, or inserts a new packed weight into the cache and returns that offset
- offset_to_addr
- gets offset and returns address to packed pointer
- reserve_space
- returns memory address with appropriate sie for XNNPACK to populate with packed weights ( I want to use the runtime_allocator for this but i don't think we have the right sizes, so for now we are just using a string buffer and resizing it)
- is_finalized
- since this cache doesn't necessarily need to care about a finalized state we always return true.
- delete_cache
- deletes cache
Differential Revision: [D70885917](https://our.internmc.facebook.com/intern/diff/D70885917/)
[ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D70885917 |
… NamedDataMap"
XNNWeightsCache Design with NamedDataMap. The intent of the weights cache is for tensors to be loaded (via name) through the named data map.
APIs to be used by XNNCompiler:
- load_unpacked_data
- Takes in a string name (tensor name). The weights cache loads the data for this string from the named data map and returns the pointer. It also creates a mapping of this pointer to the name which is later used by the XNNPACK's internal weight cache implementation
- free_unpacked_data
- Frees all the unpacked data loaded from NamedDataMap. This is only safe to call after xnn_create_runtime has been called. This is because create_runtime takes unpacked data pointers and packs them into a separate buffer.
- a couple getter methods
- get_packed_data_names
- get_unpacked_data_names
- get_num_packed_data
- get() (get's the xnn_weights_cache object)
Internal APIs used by XNNPACK Library
- look_up
- takes a cache key (weight and bias pointers) and looks up the offset to the packed weight if it exists
- look_up_or_insert
- takes a cache key and pointer to packed weights and looks_up the offset if it exists, or inserts a new packed weight into the cache and returns that offset
- offset_to_addr
- gets offset and returns address to packed pointer
- reserve_space
- returns memory address with appropriate sie for XNNPACK to populate with packed weights ( I want to use the runtime_allocator for this but i don't think we have the right sizes, so for now we are just using a string buffer and resizing it)
- is_finalized
- since this cache doesn't necessarily need to care about a finalized state we always return true.
- delete_cache
- deletes cache
Differential Revision: [D70885917](https://our.internmc.facebook.com/intern/diff/D70885917/)
[ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D70885917 |
… NamedDataMap"
XNNWeightsCache Design with NamedDataMap. The intent of the weights cache is for tensors to be loaded (via name) through the named data map.
APIs to be used by XNNCompiler:
- load_unpacked_data
- Takes in a string name (tensor name). The weights cache loads the data for this string from the named data map and returns the pointer. It also creates a mapping of this pointer to the name which is later used by the XNNPACK's internal weight cache implementation
- free_unpacked_data
- Frees all the unpacked data loaded from NamedDataMap. This is only safe to call after xnn_create_runtime has been called. This is because create_runtime takes unpacked data pointers and packs them into a separate buffer.
- a couple getter methods
- get_packed_data_names
- get_unpacked_data_names
- get_num_packed_data
- get() (get's the xnn_weights_cache object)
Internal APIs used by XNNPACK Library
- look_up
- takes a cache key (weight and bias pointers) and looks up the offset to the packed weight if it exists
- look_up_or_insert
- takes a cache key and pointer to packed weights and looks_up the offset if it exists, or inserts a new packed weight into the cache and returns that offset
- offset_to_addr
- gets offset and returns address to packed pointer
- reserve_space
- returns memory address with appropriate sie for XNNPACK to populate with packed weights ( I want to use the runtime_allocator for this but i don't think we have the right sizes, so for now we are just using a string buffer and resizing it)
- is_finalized
- since this cache doesn't necessarily need to care about a finalized state we always return true.
- delete_cache
- deletes cache
Differential Revision: [D70885917](https://our.internmc.facebook.com/intern/diff/D70885917/)
[ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D70885917 |
… NamedDataMap"
XNNWeightsCache Design with NamedDataMap. The intent of the weights cache is for tensors to be loaded (via name) through the named data map.
APIs to be used by XNNCompiler:
- load_unpacked_data
- Takes in a string name (tensor name). The weights cache loads the data for this string from the named data map and returns the pointer. It also creates a mapping of this pointer to the name which is later used by the XNNPACK's internal weight cache implementation
- free_unpacked_data
- Frees all the unpacked data loaded from NamedDataMap. This is only safe to call after xnn_create_runtime has been called. This is because create_runtime takes unpacked data pointers and packs them into a separate buffer.
- a couple getter methods
- get_packed_data_names
- get_unpacked_data_names
- get_num_packed_data
- get() (get's the xnn_weights_cache object)
Internal APIs used by XNNPACK Library
- look_up
- takes a cache key (weight and bias pointers) and looks up the offset to the packed weight if it exists
- look_up_or_insert
- takes a cache key and pointer to packed weights and looks_up the offset if it exists, or inserts a new packed weight into the cache and returns that offset
- offset_to_addr
- gets offset and returns address to packed pointer
- reserve_space
- returns memory address with appropriate sie for XNNPACK to populate with packed weights ( I want to use the runtime_allocator for this but i don't think we have the right sizes, so for now we are just using a string buffer and resizing it)
- is_finalized
- since this cache doesn't necessarily need to care about a finalized state we always return true.
- delete_cache
- deletes cache
Differential Revision: [D70885917](https://our.internmc.facebook.com/intern/diff/D70885917/)
[ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D70885917 |
facebook-github-bot
merged commit dc02cfe
into
gh/mcr229/10/base
75 of 78 checks passed
facebook-github-bot
temporarily deployed
to
cherry-pick-bot
GitHub Actions
Inactive
SS-JIA
pushed a commit
that referenced
this pull request
Mar 15, 2025
…ap (#9296) This PR was created by the merge bot to help merge the original PR into the main branch. ghstack PR number: #9154 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/10/base ghstack PR head: https://github.com/pytorch/executorch/tree/gh/mcr229/10/head Merge bot PR base: https://github.com/pytorch/executorch/tree/gh/mcr229/9/orig Merge bot PR head: https://github.com/pytorch/executorch/tree/gh/mcr229/10/orig @diff-train-skip-merge --------- Co-authored-by: Max Ren <[email protected]>
SS-JIA
pushed a commit
that referenced
this pull request
Mar 15, 2025
Pull Request resolved: #9154 XNNWeightsCache Design with NamedDataMap. The intent of the weights cache is for tensors to be loaded (via name) through the named data map. APIs to be used by XNNCompiler: - load_unpacked_data - Takes in a string name (tensor name). The weights cache loads the data for this string from the named data map and returns the pointer. It also creates a mapping of this pointer to the name which is later used by the XNNPACK's internal weight cache implementation - free_unpacked_data - Frees all the unpacked data loaded from NamedDataMap. This is only safe to call after xnn_create_runtime has been called. This is because create_runtime takes unpacked data pointers and packs them into a separate buffer. - a couple getter methods - get_packed_data_names - get_unpacked_data_names - get_num_packed_data - get() (get's the xnn_weights_cache object) Internal APIs used by XNNPACK Library - look_up - takes a cache key (weight and bias pointers) and looks up the offset to the packed weight if it exists - look_up_or_insert - takes a cache key and pointer to packed weights and looks_up the offset if it exists, or inserts a new packed weight into the cache and returns that offset - offset_to_addr - gets offset and returns address to packed pointer - reserve_space - returns memory address with appropriate sie for XNNPACK to populate with packed weights ( I want to use the runtime_allocator for this but i don't think we have the right sizes, so for now we are just using a string buffer and resizing it) - is_finalized - since this cache doesn't necessarily need to care about a finalized state we always return true. - delete_cache - deletes cache ghstack-source-id: 271823384 @exported-using-ghexport Differential Revision: [D70885917](https://our.internmc.facebook.com/intern/diff/D70885917/)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Stack from ghstack (oldest at bottom):
XNNWeightsCache Design with NamedDataMap. The intent of the weights cache is for tensors to be loaded (via name) through the named data map.
APIs to be used by XNNCompiler:
load_unpacked_data
free_unpacked_data
a couple getter methods
Internal APIs used by XNNPACK Library
Differential Revision: D70885917