Qualcomm: key the QnnManager registry on the compile options - #21934
Draft
psiddh wants to merge 1 commit into
Draft
Qualcomm: key the QnnManager registry on the compile options#21934psiddh wants to merge 1 commit into
psiddh wants to merge 1 commit into
Conversation
QnnManagerRegistry keyed managers on backend_type alone, so two specs for one backend resolved to the same manager -- the one built from whichever spec was seen first. Precision, VTCM size and SoC config all come from the options a manager was constructed with, so a graph meant to compile fp16 alongside a quantized one silently compiled at the first spec's precision instead. Mixed precision within a single program was not expressible. Keying on (backend_type, option) gives each distinct spec its own manager. Same-spec lookups still reuse one, so nothing extra is created in the common single-spec case. destroy_qnn_manager now drops every manager for a backend type rather than a single entry. Known remaining gap, not addressed here: preprocess_multimethod still takes list(compile_specs.values())[0][0], so that path applies one partition's spec to all of them even with distinct managers available. Authored with Claude Code.
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/21934
Note: Links to docs will display an error until the docs builds have been completed. ✅ You can merge normally! (1 Unrelated Failure)As of commit 0447315 with merge base b45e85d ( FLAKY - The following job failed but was likely due to flakiness present on trunk:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
meta-cla
Bot
added
the
CLA Signed
psiddh
marked this pull request as draft
August 19, 2026 07:40
This PR needs a
|
This file contains hidden or 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
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.
QnnManagerRegistry keyed managers on backend_type alone, so two specs for one backend resolved to the same manager (two compile specs for one backend silently share a QnnManager) , the one built from whichever spec was seen first. Precision, VTCM size and SoC config all come from the options a manager was constructed with, so a graph meant to compile fp16 alongside a quantized one silently compiled at the first spec's precision instead. Mixed precision within a single program was not expressible.
Keying on (backend_type, option) gives each distinct spec its own manager. Same-spec lookups still reuse one, so nothing extra is created in the common single-spec case. destroy_qnn_manager now drops every manager for a backend type rather than a single entry.
Known remaining gap, not addressed here: preprocess_multimethod still takes list(compile_specs.values())[0][0], so that path applies one partition's spec to all of them even with distinct managers available.