[QNN EP] Accept htp_arch 79 (v79, Snapdragon 8 Elite) - #31638
Open
guptaishaan wants to merge 1 commit into
Open
Conversation
ParseHtpArchitecture() handled 0/68/69/73/75/81 and had no case for 79, so htp_arch=79 was logged as "Invalid HTP architecture: 79" and silently downgraded to QNN_HTP_DEVICE_ARCH_NONE. No arch device config was then pushed in CreateDevice(), leaving no way to pin the architecture on SM8750 class parts. QNN_HTP_DEVICE_ARCH_V79 = 79 has been defined in QNN/HTP/QnnHtpDevice.h for several QAIRT releases. Also adds 79 to the hardcoded supported_htp_archs sets in onnx_test_runner and onnxruntime_perf_test, which threw on it, and to the htp_arch list in the C API docs. New test QnnHTPBackendTests.HTPArchV79 creates a QNN EP with htp_arch=79 under an Env with a capturing log callback and asserts the "Invalid HTP architecture" warning is not emitted. It fails before this change and passes after. Verified on Linux x86_64 against QAIRT 2.42.0.251225. No Snapdragon device was available, so deviceCreate() was never called with a v79 arch config; only the option parsing was exercised.
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
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
1 participant
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.
Fixes #31353
ParseHtpArchitecture()handles0/68/69/73/75/81and has no case for79, sohtp_arch=79islogged as
Invalid HTP architecture: 79and silently downgraded toQNN_HTP_DEVICE_ARCH_NONE. v79 isthe HTP architecture of SM8750 (Snapdragon 8 Elite), and
QNN_HTP_DEVICE_ARCH_V79 = 79has been inQNN/HTP/QnnHtpDevice.hfor several QAIRT releases, so this is just a missing branch. The twohardcoded
supported_htp_archssets inonnx_test_runnerandonnxruntime_perf_test, and thehtp_archlist in the C API docs, had the same gap.Scope note: this makes
htp_arch=79work on 8 Elite class parts, which is the workaround thereporter tried and could not use. I could not confirm it resolves the
QNN_DEVICE_ERROR_INVALID_CONFIGthey see with no provider options set - that comes back fromdeviceCreate()with an empty config list, which points at SoC detection inside the QNN HTP backendrather than at ORT.
Verified on Linux x86_64 with QAIRT 2.42.0.251225, the SDK version the Linux QNN CI leg pins:
QnnHTPBackendTests.HTPArchV79fails before the change (Invalid HTP architecture: 79in thecaptured EP log) and passes after.
onnxruntime_perf_test -i "htp_arch|79"threwWrong value for htp_arch. select from: 0,68,69,73,75,81before, and is accepted after.onnxruntime_provider_test --gtest_filter='Qnn*'gives an identical result set before and after.lintrunner -m HEADclean.Not verified: no Snapdragon device was available, and the QAIRT x86_64 HTP library needs a newer
glibc than this host has, so
deviceCreate()was never actually called with a v79 arch config. Onlythe ORT side parsing was exercised. Windows, Android arm64 and the static_lib QNN build were not
compiled.
Thanks to @ivaylo681-dev for the detailed report, including the logcat that pinned the rejected
value to
ParseHtpArchitecture.