Project

General

Profile

Forums » Software Development »

DCAdreno GPU userspace: newer OpenCL driver (cl_qcom_ml_ops)? + headless Vulkan notes

Added by David Cuccia 3 days ago

Hi Critical Link team,

We are evaluating the MitySOM-QCS6490 for a medical imaging product. I've been able to get up and running with the dev kit and I'm experimenting with FP32 ML inference on the Adreno 643 GPU (headless, containerized, no display stack). Image: kernel 6.6.90-qli-1.5-ver.1.1, Adreno userspace build 0808.9 (driver id 6d02bd6aff, 06/12/25, compiler E031.49.02.00). OpenCL and Vulkan compute both work for us. We (me and my trusty Fable 5 bot ) hit three items we would like your input on:

  1. Is a newer Adreno GPU userspace drop available or planned for the MitySOM-QCS6490 (QLI 1.6+)? Specifically, we are looking for a driver that exposes the cl_qcom_ml_ops OpenCL extension (used by Qualcomm''s Adreno OpenCL ML SDK and TVM''s CLML backend); the shipped 0808.9 driver does not report it. Relatedly: if the second-spin dev kit ships with a refreshed BSP, can the GPU userspace also be updated independently on existing kits?
  2. Minor: Vulkan loader-interface version. The shipped libvulkan_adreno.so.1 negotiates loader interface v3 while advertising Vulkan 1.2 in the manifest, so current Khronos loaders emit a Policy #LDP_DRIVER_7 warning (harmless — enumeration and compute work). A driver built for interface v5 would silence it.
  3. Documentation suggestion (headless Vulkan). Two things cost us time and may help other customers: (a) no Vulkan ICD manifest is wired up on the image — point VK_ICD_FILENAMES at /usr/share/vulkan/icd.d/adrenovk.json or create one for libvulkan_adreno.so.1; (b) the driver requires /dev/dri/renderD128 (from msm_drm) at instance creation even for headless compute — with only /dev/kgsl-3d0 visible (e.g. in a minimal container), vkCreateInstance fails with VK_ERROR_OUT_OF_HOST_MEMORY, which is easy to misread as a driver defect.

Attachments: vulkaninfo --summary (success, with the LDP_DRIVER_7 warning visible) and the clinfo device-extensions list from build 0808.9. Happy to test any driver drop candidates — we have containerized benchmarks that validate OpenCL + Vulkan compute end-to-end in minutes.

Thanks!

Download all files
1-vulkaninfo-summary.txt (3.87 KB) 1-vulkaninfo-summary.txt
0-README.txt (1.54 KB) 0-README.txt
2-clinfo-full.txt (17.2 KB) 2-clinfo-full.txt

Replies (2)

GG RE: Adreno GPU userspace: newer OpenCL driver (cl_qcom_ml_ops)? + headless Vulkan notes - Added by Gregory Gluszek about 23 hours ago

Hi David,

Regarding Item 1:

We are currently working on support for for QLI 2.0 as our next release. Below is a table my buddy Opus created based our current release and some internal WIP updates we have:

QLI 1.5 QLI 1.6 QLI 1.7 QLI 1.8 QLI 2.0
--- --- --- --- --- ---
Distro version 1.5-ver.1.1 1.6-ver.1.2.1 1.7-ver.1.1 1.8-ver.1.1 2.0
Kernel 6.6.90-qli-1.5 6.6.97-qli-1.6 6.6.116-qli-1.7 6.6.119-qli-1.8 6.18.30
Adreno driver build 0808.9 0808.12 0838.3 0855.2 0855.5
Compiler E031.49.02.00 E031.49.02.00 E031.50.15.00 E031.50.31.01 E031.50.31.01
`CL_DEVICE_NAME` `QUALCOMM Adreno(TM) 643` `QUALCOMM Adreno(TM) 643` `QUALCOMM Adreno(TM) 643` `QUALCOMM Adreno(TM) 643` `QUALCOMM ` (truncated)
OpenCL platforms 1 1 1 1 2 (adds Mesa `rusticl`, 0 devices)
Total extensions 34 34 34 34 57
`cl_qcom_*` extensions 18 18 18 18 —
CLML entry points loader stubs only, return `CL_INVALID_VALUE` loader stubs only, return `CL_INVALID_VALUE` loader stubs only, return `CL_INVALID_VALUE` loader stubs only, return `CL_INVALID_VALUE` resolve via `clGetExtensionFunctionAddressForPlatform`
`cl_qcom_ml_ops` no no no no yes

Regarding updating the GPU userspace independently, we have found that all the parts of a release are typically tied together pretty closely. I would say there is decent risk of complications with trying to do something like attempting to update just the Adreno driver for QLI 1.5 to get cl_qcom_ml_ops support. Can you detail what interfaces you need to be functional for your application and as soon as we have a prelim build that supports QLI 2.0 and your required interfaces we could share that to get you running on 2.0 ASAP.

Regarding Item 2:

Thank you for sharing. I will check if this is still an issue with QLI 2.0.

Regarding Item 3:

Thank you for sharing as well. I will look into addressing this.

Thanks,
Greg

DC RE: Adreno GPU userspace: newer OpenCL driver (cl_qcom_ml_ops)? + headless Vulkan notes - Added by David Cuccia about 4 hours ago

Hi Greg,

Fantastic — thank you. A preliminary QLI 2.0 build would be very welcome. The interfaces we need functional, in priority order:

Must-have (our current working paths — regression-sensitive):
  1. OpenCL 3.0 on the Adreno 643 — headless, from a container: /dev/kgsl-3d0 + /dev/dma_heap/system passthrough, libOpenCL.so.1 > libOpenCL_adreno.so.1 and its dlopen closure (libgsl/libCB/libq3dtools_adreno/libadreno_utils/libllvm*). We validate with clinfo/clpeak + our own FP32 conv-net benchmarks.
  2. Vulkan compute on the Adreno 643 — headless instance creation + compute queue (no WSI/display). Today this needs an ICD manifest for libvulkan_adreno.so.1 and /dev/dri/renderD128; either keeping that recipe working or wiring a manifest into the image is fine. We validate with vulkaninfo + ncnn compute.
  3. Docker/containers (we bind-mount the host GPU userspace read-only into ubuntu:24.04-based containers — glibc compatibility of the Adreno userspace matters; 1.5''s build needed glibc >= 2.39).
The new capability we want to exercise (the reason for the ask):
  1. cl_qcom_ml_ops / CLML with entry points resolving via clGetExtensionFunctionAddressForPlatform — FP16/FP32 ML ops on the GPU. We plan to drive it via TVM's CLML backend and/or direct CLML calls.
Nice-to-have / please don't regress:
  1. cl_qcom_recordable_queues, cl_khr_fp16, cl_qcom_ext_host_ptr(_iocoherent), cl_khr_image2d_from_buffer (zero-copy paths)
  2. USB host on the USB-A port + RTL8153 USB-Ethernet (our only network path — a USB-C VBUS issue we saw kept us from using that for a network adapter: Unable to get vbus regulator err: -19, supply pm_ivbus_bd)
  3. OSTree layout compatibility (we install only to /usr/local, /opt, /home, /etc) and working opkg/BusyBox userland assumptions, or release notes on what changed with the 6.18 kernel jump

We can turn around validation results on a prelim build quickly. Also, for the dev kit with the newer production-speed RAM, will it ship with QLI 1.5?

Thanks!
David

    (1-2/2)
    Go to top