[ET-VK] Fix SDK event_name for inputs and outputs
#7738
Merged
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
## Issue In the ET-SDK, we assign an `event_name` to each operation. In ET-VK, we compose a unique `event_name` using the `node_id`. The `node_id` exists for every `OperatorCall` but not for input/output with `nchw_to_image`/`image_to_nchw`. Those cases collapse into `node_id == 0` which means all `nchw_to_image` had the same `event_name` and hence only one was stored. The same reasoning results in storage of only one `image_to_nchw`. ## Solution Ignore the serialized `node_id` and use the operation's `prepack_node`/`execute_node` vector index. TODO: Determine if we can remove the serialized `node_id`, or whether this should be fixed differently and still reference it. Differential Revision: [D68344534](https://our.internmc.facebook.com/intern/diff/D68344534/) [ghstack-poisoned]
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/7738
Note: Links to docs will display an error until the docs builds have been completed. ❌ 1 New FailureAs of commit 1e86abe with merge base 8611aaa ( NEW FAILURE - The following job has failed:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
facebook-github-bot
added
the
CLA Signed
jorgep31415
added a commit
that referenced
this pull request
Jan 17, 2025
## Issue In the ET-SDK, we assign an `event_name` to each operation. In ET-VK, we compose a unique `event_name` using the `node_id`. The `node_id` exists for every `OperatorCall` but not for input/output with `nchw_to_image`/`image_to_nchw`. Those cases collapse into `node_id == 0` which means all `nchw_to_image` had the same `event_name` and hence only one was stored. The same reasoning results in storage of only one `image_to_nchw`. ## Solution Ignore the serialized `node_id` and use the operation's `prepack_node`/`execute_node` vector index. TODO: Determine if we can remove the serialized `node_id`, or whether this should be fixed differently and still reference it. Differential Revision: [D68344534](https://our.internmc.facebook.com/intern/diff/D68344534/) ghstack-source-id: 261951242 Pull Request resolved: #7738
|
This pull request was exported from Phabricator. Differential Revision: D68344534 |
jorgep31415
added
the
release notes: vulkan
SS-JIA
approved these changes
Jan 17, 2025
## Issue In the ET-SDK, we assign an `event_name` to each operation. In ET-VK, we compose a unique `event_name` using the `node_id`. The `node_id` exists for every `OperatorCall` but not for input/output with `nchw_to_image`/`image_to_nchw`. Those cases collapse into `node_id == 0` which means all `nchw_to_image` had the same `event_name` and hence only one was stored. The same reasoning results in storage of only one `image_to_nchw`. ## Solution Ignore the serialized `node_id` and use the operation's `prepack_node`/`execute_node` vector index. TODO: Determine if we can remove the serialized `node_id`, or whether this should be fixed differently and still reference it. Differential Revision: [D68344534](https://our.internmc.facebook.com/intern/diff/D68344534/) [ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D68344534 |
## Issue In the ET-SDK, we assign an `event_name` to each operation. In ET-VK, we compose a unique `event_name` using the `node_id`. The `node_id` exists for every `OperatorCall` but not for input/output with `nchw_to_image`/`image_to_nchw`. Those cases collapse into `node_id == 0` which means all `nchw_to_image` had the same `event_name` and hence only one was stored. The same reasoning results in storage of only one `image_to_nchw`. ## Solution Ignore the serialized `node_id` and use the operation's `prepack_node`/`execute_node` vector index. TODO: Determine if we can remove the serialized `node_id`, or whether this should be fixed differently and still reference it. Differential Revision: [D68344534](https://our.internmc.facebook.com/intern/diff/D68344534/) [ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D68344534 |
facebook-github-bot
merged commit 0bbdabe
into
gh/jorgep31415/129/base
45 of 47 checks passed
facebook-github-bot
temporarily deployed
to
cherry-pick-bot
GitHub Actions
Inactive
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):
event_namefor inputs and outputs #7738Issue
In the ET-SDK, we assign an
event_nameto each operation. In ET-VK, we compose a uniqueevent_nameusing thenode_id. Thenode_idexists for everyOperatorCallbut not for input/output withnchw_to_image/image_to_nchw. Those cases collapse intonode_id == 0which means allnchw_to_imagehad the sameevent_nameand hence only one was stored. The same reasoning results in storage of only oneimage_to_nchw.Solution
Ignore the serialized
node_idand use the operation'sprepack_node/execute_nodevector index.TODO: Determine if we can remove the serialized
node_id, or whether this should be fixed differently and still reference it.Differential Revision: D68344534