• Locked Locked
  • Replies 15 replies
  • Subscribers 137 subscribers
  • Views 16601 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Mali OpenCL SDK not found

Santy

Hi,

    I'm trying to get the 64 bit OpenCL 1.2 libraries onto my Android development board. My goal is to finally use ARM Compute Library with OpenCL on Android. 

   I see that since Android 4.x onwards OpenCL support was stopped by Google (probably to promote Renderscript). 

   The Mali OpenCL SDK (refered from Khronos website) seems broken.

    The Mali SDK Home page has a link for Mali OpenCL SDK which is getting redirected to ARM Compute Library page. 

    The ARM Compute Library has suupport for Android and has OpenCL Stubs and asking the user to use the real libOpenCL.so library

    My guess is that the Mali OpenCL SDK page is temporarily down for maintainence. 

    Could someone help please? 

    Where do I find the OpenCL 1.2 SDK? 

    How do I (cross) compile the OpenCL 1.2 libraries for Android? 

    I don't want to port the Mali OpenCL SDK into Android build system and build from within Android SDK. I'm fine using a standalone Android toolchain to cross-compile the Mali OpenCL SDK and copying the libraries onto my target. 

    Thank you.

Regards,

San

Parents

  • Hi all,

    Driver binaries for any given chipset - whether for graphics or compute APIs - generally need to be sourced from the chipset provider or the device manufacturer. We don't provide drivers directly at all, except for a small number of test platforms such as the Arm Juno development board. In most cases the drivers are customized by the chipset provider - e.g. to add support for GPU power management which is outside of the Mali GPU itself - so we are unable to provide binaries directly. Not all chipset providers will provide an OpenCL driver - many simply want to support graphics use cases.

    The OpenCL SDK contains demo applications showing how to use OpenCL - it doesn't actually contain the OpenCL driver libraries themselves.

    The ARM Compute Library is a library which itself is effectively built on top of the platform's OpenCL driver, so again doesn't include the OpenCL library itself. The stub library included is just for cross-compilation to provide something to link against; it's not a real library implementation.

    For any specific device you might find that the libGLES_mali.so graphics library on the platform actually also exports the OpenCL symbols; if you create a symlink to that call libOpenCL.so then you might find it works. Running "strings" over the library will let you know which symbols it exports.

    Pete

Reply

  • Hi all,

    Driver binaries for any given chipset - whether for graphics or compute APIs - generally need to be sourced from the chipset provider or the device manufacturer. We don't provide drivers directly at all, except for a small number of test platforms such as the Arm Juno development board. In most cases the drivers are customized by the chipset provider - e.g. to add support for GPU power management which is outside of the Mali GPU itself - so we are unable to provide binaries directly. Not all chipset providers will provide an OpenCL driver - many simply want to support graphics use cases.

    The OpenCL SDK contains demo applications showing how to use OpenCL - it doesn't actually contain the OpenCL driver libraries themselves.

    The ARM Compute Library is a library which itself is effectively built on top of the platform's OpenCL driver, so again doesn't include the OpenCL library itself. The stub library included is just for cross-compilation to provide something to link against; it's not a real library implementation.

    For any specific device you might find that the libGLES_mali.so graphics library on the platform actually also exports the OpenCL symbols; if you create a symlink to that call libOpenCL.so then you might find it works. Running "strings" over the library will let you know which symbols it exports.

    Pete

Children