Adreno libOpenCL_system.so (Android /system_ext/lib64) is not ICD-loader compatible — heads-up for anyone chasing this path

[Skuddi]

Adreno libOpenCL_system.so (Android /system_ext/lib64) is not ICD-loader compatible — heads-up for anyone chasing this path

Device: RedMagic 10 Pro, Snapdragon 8 Elite (SM8750), Adreno 830, Android 16, no root. Running llama.cpp under Termux (Android userspace terminal, no NDK/system-app context).

Why I went looking

The usual vendor OpenCL blob (/vendor/lib64/libOpenCL_adreno.so) is blocked for non-system apps by Android's Bionic linker namespace. But there's a second, less-known driver: /system_ext/lib64/libOpenCL_system.so. It's a normal system library (no namespace restriction), loads cleanly, and exports standard, correctly-working cl* symbols — clGetPlatformIDs/clGetPlatformInfo/clGetDeviceIDs/clGetDeviceInfo all work fine when called directly (confirmed: "QUALCOMM Snapdragon(TM)" / "Adreno (TM) 830" / OpenCL 3.0).

Termux already ships llama-cpp-backend-opencl (-DGGML_OPENCL=ON), and ocl-icd (the ICD loader Termux's libOpenCL.so is built on) just needs a .icd vendor file pointing at the driver. So I pointed it there, expecting this to just work.

What actually happens

Two separate, real problems, in sequence:

1. clIcdGetPlatformIDsKHR (the ICD-specific platform-enumeration entry point) is broken in this driver. It returns CL_SUCCESS with 0 platforms, while the standard clGetPlatformIDs on the same library correctly returns 1. ocl-icd (and presumably any standard ICD loader, since this is the entry point they're specified to prefer) ends up with "no platforms" and skips the ICD entirely.

Workaround: a ~10-line shim .so that just forwards clIcdGetPlatformIDsKHR to the real clGetPlatformIDs (linked against the real driver as a direct dependency, so every other cl* symbol stays reachable transitively via dlsym). Point the .icd file at the shim instead of the driver directly. This gets the loader to Try to load 1 platforms.

2. Right after that, the loader crashes dereferencing the platform handle. Traced to ocl-icd's KHR_ICD2_HAS_TAG check:

#define KHR_ICD2_HAS_TAG(object) \
  (((intptr_t)((object)->dispatch->clGetPlatformIDs)) == CL_ICD2_TAG_KHR)

This assumes every cl_platform_id begins with a dispatch-table pointer — a core requirement of the OpenCL ICD spec itself, not an ocl-icd quirk. I checked the actual handle value this driver hands back: a small, non-pointer-looking value (0xde763ed3), nowhere near any mapped memory region (the library itself is mapped around 0x77a3ee...). Dereferencing it segfaults immediately, reproducibly.

Conclusion

This driver's platform/device handles aren't ICD-dispatch-table-based at all — likely because it was built for direct internal linking by system apps that call it as the implementation, never for generic multi-vendor ICD loading. That's a structural ABI mismatch with the ICD spec, not a loader bug, and not something fixable with a small patch — every place a loader dereferences the handle through a dispatch table would need to go, which is close to a full rewrite of the dispatch mechanism, not a patch.

Posting this mainly because I noticed a lot of active Adreno-specific work in ggml-opencl recently (dedicated matmul paths per Adreno generation, MoE fusion, etc.) — if anyone else on a similar Snapdragon/Android/Termux setup finds /system_ext/lib64/libOpenCL_system.so and is tempted to route the ICD loader at it like I was: it doesn't work, and here's why, so you don't have to re-derive it.

Happy to share the shim source and repro steps if useful to anyone.

[Skuddi]

Update: the ICD-loader analysis above still stands, but there's a working bypass

Follow-up after finding a working path, wanted to correct the record rather than leave the conclusion above standing as-is.

The ICD-loader-specific diagnosis (broken clIcdGetPlatformIDsKHR, non-dispatch-table platform handle) is still accurate — that mechanism genuinely doesn't work with ocl-icd or any standard ICD loader on this driver.

But it turns out that's only a blocker for the generic ICD dispatch path, not for OpenCL on this device in general. Linking ggml-opencl directly against /system_ext/lib64/libOpenCL_system.so (-lOpenCL_system instead of the standard -lOpenCL, skipping ocl-icd/the .icd vendor-file mechanism entirely) sidesteps the problem completely — because ggml-opencl never dereferences the platform/device handle itself, it just passes it back into the driver's own real cl* functions, which is exactly how OpenCL handles are supposed to be treated.

Tested just now:

• llama-cli --list-devices → GPUOpenCL: QUALCOMM Adreno(TM) 830 — no crash, the exact step that died before.
• Real inference (phi4-mini-instruct, Q4_K_M, -ngl 999 -c 4096 -t 8 -fa 1 -ub 128): correct, coherent output, 97.4 t/s prompt / 19.0 t/s generation — actually faster than this device's Vulkan/Turnip path for the same model.

Only tested a single short prompt so far, not a full test suite, so treat this as "promising, not fully validated" rather than a confirmed fix. But the driver is clearly usable for real inference when you don't route through the generic ICD dispatch mechanism — worth knowing before anyone reads the original post and rules the whole device out.