[Mobile] QNN EP: QNN_DEVICE_ERROR_INVALID_CONFIG on Snapdragon 8 Elite (SM8750P, soc_id=639) — device creation fails regardless of provider_options, onnxruntime-android-qnn

[ivaylo681-dev]

Describe the issue

QNN EP: QNN_DEVICE_ERROR_INVALID_CONFIG on Snapdragon 8 Elite (SM8750P, soc_id=639) — device creation fails regardless of provider_options, onnxruntime-android-qnn

Migrated from: microsoft/onnxruntime#31353 (per maintainer request to file here instead)
Related: microsoft/onnxruntime#31638 (fixes a separate htp_arch=79 parser gap, doesn't resolve this issue — see below)

Summary

OrtSession creation with the QNN HTP execution provider fails at device creation with QNN_DEVICE_ERROR_INVALID_CONFIG, regardless of provider_options, model, or onnxruntime-android-qnn version tested. Confirmed via a separate ORT maintainer's review (on #31638) that this is not an ORT-side parsing issue — it's returned by deviceCreate() with an empty config list, pointing at SoC detection inside the QNN HTP native backend.

Device

• SoC model: SM8750P (adb shell getprop ro.soc.model)
• Board platform: sun (adb shell getprop ro.board.platform)
• soc_id: 639 (adb shell cat /sys/devices/soc0/soc_id)
• OS: Android 16, MIUI/HyperOS (Xiaomi)
• onnxruntime-android-qnn versions tested: 1.27.0, 1.28.0 — identical failure on both

Error (identical across every attempt)

W onnxruntime: [qnn_backend_manager.cc:1680 SetupBackend] Failed to setup so cleaning up
E onnxruntime: [qnn_execution_provider.cc:1046 GetCapability] QNN SetupBackend failed Failed to create device. Error: QNN_DEVICE_ERROR_INVALID_CONFIG: Invalid config values

Session creation itself doesn't throw — GetCapability() silently assigns 100% of graph nodes to CPU. Confirmed via enableProfiling() trace: every node shows "provider": "CPUExecutionProvider", zero occurrences of "QNN" in the raw trace.

Ruled out (exhaustively tested)

Variable | Tested | Result -- | -- | -- htp_arch | unset, 81, 79, 69 | No change soc_model | 69, and every integer 0–9999 (brute-forced with session.disable_cpu_ep_fallback forcing a hard failure signal on any partial success) | No change — identical error every value Model precision | fp32, native fp16 | No change — fails before model evaluation onnxruntime-android-qnn version | 1.27.0, 1.28.0 | Identical qnn-runtime native library version | bundled vs. explicit override to 2.48.0 (confirmed via file-size diff on installed APK: 2,642,248 → 3,760,632 bytes) | No change Manual ADSP_LIBRARY_PATH | present vs. removed | No change vtcm_mb | unset vs. 8 | No change Op-level HTP support | checked all model ops against QNN's published operator table — all supported | Not the cause; fails before op-level partitioning DSP device-node permissions | initially suspected, then disproven — Geekbench AI (third-party, no elevated privileges) achieves real HTP acceleration on this exact device via its own TFLite QNN backend (large FP16/INT8 score differential vs. its NNAPI backend: 21,627/55,112 vs. 485/1,111) | Not a permissions issue

Independent cross-check via a different framework

Reproduced the identical native failure via TensorFlow Lite's QNN delegate (com.qualcomm.qti:qnn-litert-delegate), independent of ORT entirely:

E QnnDsp: QnnDsp <E> loadRemoteSymbols failed with err 4000
E QnnDsp: QnnDsp <E> Failed to create transport for device, error: 4000
E QnnDsp: QnnDsp <E> Failed to load skel, error: 4000

Same error code (4000) as a previously-resolved report for a related device (pytorch/executorch#16465, soc_id=705, fixed via a SoC-ID table addition mapping to soc_model=105 in QAIRT 2.43.0). This strongly suggests soc_id=639 (SM8750P) needs its own equivalent table entry, not yet present even in qnn-runtime 2.48.0.

Also tried via ExecuTorch (different framework, same underlying QNN stack)

Using ExecuTorch's --soc_model "SM8750" (string-based family-name override, a mechanism ORT's soc_model doesn't support — ORT's option only accepts integers and throws stoi: no conversion on a string), QNN device creation and graph compilation succeed on this same device (details: pytorch/executorch#21586). This confirms the chip and QAIRT SDK combination is capable — the blocker is specifically SoC-ID recognition, not the hardware itself.

Also filed with Qualcomm directly

Currently in contact with Qualcomm support (mysupport.qualcomm.com) regarding the underlying qnn-runtime/QAIRT SoC-ID table gap for soc_id=639, since that's ultimately where this needs to be resolved. Filing here too since onnxruntime-android-qnn is the artifact that would need a version bump once/if that's fixed, and to confirm from the ORT side whether there's anything ORT-specific worth checking (e.g. whether ORT's QNN EP could support a string-based soc_model override the way ExecuTorch does, as a possible workaround independent of the SoC-ID table itself).

Request

• Can onnxruntime-android-qnn support a string-based soc_model value (chip family name, e.g. "SM8750") the way ExecuTorch's equivalent option does, as a potential workaround independent of waiting on Qualcomm's SoC-ID table?

To reproduce

QNN EP: QNN_DEVICE_ERROR_INVALID_CONFIG on Snapdragon 8 Elite (SM8750P, soc_id=639) — device creation fails regardless of provider_options, onnxruntime-android-qnn

Migrated from: microsoft/onnxruntime#31353 (per maintainer request to file here instead)
Related: microsoft/onnxruntime#31638 (fixes a separate htp_arch=79 parser gap, doesn't resolve this issue — see below)

Summary

OrtSession creation with the QNN HTP execution provider fails at device creation with QNN_DEVICE_ERROR_INVALID_CONFIG, regardless of provider_options, model, or onnxruntime-android-qnn version tested. Confirmed via a separate ORT maintainer's review (on #31638) that this is not an ORT-side parsing issue — it's returned by deviceCreate() with an empty config list, pointing at SoC detection inside the QNN HTP native backend.

Device

• SoC model: SM8750P (adb shell getprop ro.soc.model)
• Board platform: sun (adb shell getprop ro.board.platform)
• soc_id: 639 (adb shell cat /sys/devices/soc0/soc_id)
• OS: Android 16, MIUI/HyperOS (Xiaomi)
• onnxruntime-android-qnn versions tested: 1.27.0, 1.28.0 — identical failure on both

Error (identical across every attempt)

W onnxruntime: [qnn_backend_manager.cc:1680 SetupBackend] Failed to setup so cleaning up
E onnxruntime: [qnn_execution_provider.cc:1046 GetCapability] QNN SetupBackend failed Failed to create device. Error: QNN_DEVICE_ERROR_INVALID_CONFIG: Invalid config values

Session creation itself doesn't throw — GetCapability() silently assigns 100% of graph nodes to CPU. Confirmed via enableProfiling() trace: every node shows "provider": "CPUExecutionProvider", zero occurrences of "QNN" in the raw trace.

Ruled out (exhaustively tested)

Variable | Tested | Result -- | -- | -- htp_arch | unset, 81, 79, 69 | No change soc_model | 69, and every integer 0–9999 (brute-forced with session.disable_cpu_ep_fallback forcing a hard failure signal on any partial success) | No change — identical error every value Model precision | fp32, native fp16 | No change — fails before model evaluation onnxruntime-android-qnn version | 1.27.0, 1.28.0 | Identical qnn-runtime native library version | bundled vs. explicit override to 2.48.0 (confirmed via file-size diff on installed APK: 2,642,248 → 3,760,632 bytes) | No change Manual ADSP_LIBRARY_PATH | present vs. removed | No change vtcm_mb | unset vs. 8 | No change Op-level HTP support | checked all model ops against QNN's published operator table — all supported | Not the cause; fails before op-level partitioning DSP device-node permissions | initially suspected, then disproven — Geekbench AI (third-party, no elevated privileges) achieves real HTP acceleration on this exact device via its own TFLite QNN backend (large FP16/INT8 score differential vs. its NNAPI backend: 21,627/55,112 vs. 485/1,111) | Not a permissions issue

Independent cross-check via a different framework

Reproduced the identical native failure via TensorFlow Lite's QNN delegate (com.qualcomm.qti:qnn-litert-delegate), independent of ORT entirely:

E QnnDsp: QnnDsp <E> loadRemoteSymbols failed with err 4000
E QnnDsp: QnnDsp <E> Failed to create transport for device, error: 4000
E QnnDsp: QnnDsp <E> Failed to load skel, error: 4000

Same error code (4000) as a previously-resolved report for a related device (pytorch/executorch#16465, soc_id=705, fixed via a SoC-ID table addition mapping to soc_model=105 in QAIRT 2.43.0). This strongly suggests soc_id=639 (SM8750P) needs its own equivalent table entry, not yet present even in qnn-runtime 2.48.0.

Also tried via ExecuTorch (different framework, same underlying QNN stack)

Using ExecuTorch's --soc_model "SM8750" (string-based family-name override, a mechanism ORT's soc_model doesn't support — ORT's option only accepts integers and throws stoi: no conversion on a string), QNN device creation and graph compilation succeed on this same device (details: pytorch/executorch#21586). This confirms the chip and QAIRT SDK combination is capable — the blocker is specifically SoC-ID recognition, not the hardware itself.

Also filed with Qualcomm directly

Currently in contact with Qualcomm support (mysupport.qualcomm.com) regarding the underlying qnn-runtime/QAIRT SoC-ID table gap for soc_id=639, since that's ultimately where this needs to be resolved. Filing here too since onnxruntime-android-qnn is the artifact that would need a version bump once/if that's fixed, and to confirm from the ORT side whether there's anything ORT-specific worth checking (e.g. whether ORT's QNN EP could support a string-based soc_model override the way ExecuTorch does, as a possible workaround independent of the SoC-ID table itself).

Request

• Can onnxruntime-android-qnn support a string-based soc_model value (chip family name, e.g. "SM8750") the way ExecuTorch's equivalent option does, as a potential workaround independent of waiting on Qualcomm's SoC-ID table?

Urgency

high

Platform

Android

OS Version

16

ONNX Runtime QNN Installation

Released Package

Compiler Version (if 'Built from Source')

No response

ONNX Runtime Version or Commit ID

1.28.0

ONNX Runtime API

None

Architecture

X64

ONNX Runtime QNN Version or Commit ID

1.28.0

QAIRT version

2.48.0