OpenCL support for Mali-T628 MP6 on Arndale Octa?

Hi Rich,

Good to know the difference between X11 and fbdev. I have one follow-up question on this. So far I have linked my OpenCL programs to libmali.so from the userspace binary package instead of using the libOpenCL.so, since libOpenCL.so gives me lots of undefined reference errors whilst using libmali.so, compilation progresses without any errors. I also noticed that libmali.so is the only substantial file in the package:

# ll ../fbdev/

total 21056

drwxr-xr-x  2 root  root      4096 Jan  1  2000 ./

drwx------ 11 root  root      4096 Jan  1  2000 ../

-rwxr-x---  1 16580 16580     4806 Jul 23 14:44 libEGL.so*

-rwxr-x---  1 16580 16580     4806 Jul 23 14:44 libGLESv1_CM.so*

-rwxr-x---  1 16580 16580     4806 Jul 23 14:44 libGLESv2.so*

-rwxr-x---  1 16580 16580     4806 Jul 23 14:44 libOpenCL.so*

-rwxr-x---  1 16580 16580 21518354 Jul 23 14:44 libmali.so*

Is using libmali.so to lik against the correct way to go?

Regarding DVFS, the /device/dvfs file is not present on my system:

# tree /sys/class/misc/mali0

/sys/class/misc/mali0

├── dev

├── device -> ../../../11800000.mali

├── power

│   ├── autosuspend_delay_ms

│   ├── control

│   ├── runtime_active_time

│   ├── runtime_status

│   └── runtime_suspended_time

├── subsystem -> ../../../../class/misc

└── uevent

3 directories, 7 files

And your command results in a permission denied error, even though I am using a root shell:

# echo off > /sys/class/misc/mali0/device/dvfs

-bash: /sys/class/misc/mali0/device/dvfs: Permission denied

I am looking forward to seeing your clpeak results!

Hi bramv,

"libOpenCL.so" is the spec defined library name that OpenCL should be exposed as on the platform. In our case we implement this (and the GLES libs) as shims which pass through to the libmali.so binary, which is why that's the largest one there. For development purposes you can link against either, but obviously you wouldn't want to do this for a release, you'd want to link against libOpenCL.so for portability.

That said, it SHOULD work, so if you are having issues linking against libOpenCL.so feel free to share them here and we will take a look. I can't think of a good reason why one should work and the other fail.

Thanks,

Chris

All the errors are undefined reference errors at link time, the symbols should be there so offhand not sure why that's happening, but in any case linking against libmali.so is working

In your above output, ldd a.out is reporting /usr/lib/libmali.so on the first line, so thats working as expected.

Hth,

Chris

Hi Chris,

I put all files from the binary userspace driver in the /usr/lib/ directory and compiled just using: "g++ program.cpp -lOpenCL". This gives the same result as compiling like this: "g++ program.cpp /usr/lib/libOpenCL.so". The output is too long to show here.

Compiling using "g++ clpeak-arndale-octa.cpp /usr/lib/libmali.so" works just fine: But now that I am further looking into the compilation, I noticed the following:

# ldd a.out

  /usr/lib/libmali.so (0xb5e03000)

  libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb5d4a000)

  libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb5cde000)

  libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb5cbd000)

  libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb5bd6000)

  /lib/ld-linux-armhf.so.3 (0xb6f6d000)

  librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb5bc8000)

  libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb5bac000)

  libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb5ba1000)

The resulting binary does not contain any reference to a OpenCL or Mali library. Does this mean that the program runs on the CPU instead of GPU? But then, why does it report the two Mali-T628 devices? I am confused.

Whoops, I missed that line. In that case I can conclude the following:

I am running a kernel containing the proper Mali kernel driver, my program is linked to the corresponding userspace binary and T628-MP6 is correctly recognized.

Is it indeed DVFS that is preventing the benchmark to achieve the expected performance level? Why is /sys/class/misc/mali0/device/dvfs missing?

With regards to the Linker errors, you should be able to fix the issue by linking against both mali and OpenCL.  OpenCL will provide the runtime linker target (even in the absence of mali) whilst mali will provide the symbols at compile time, stopping the errors in your shared paste.

Hope this helps,

Rich

Hi Rich,

I just tried to run the GPU benchmark while the CPU was busy compiling a new kernel. There are however no significant differences in the results.

To see whether I could make DVFS work, I enabled "CONFIG_MALI_MIDGARD_DVFS=y", but this results in undefined references while compiling:

  LD      init/built-in.o

drivers/built-in.o: In function `mali_dvfs_update_asv':

:(.text+0x517a8): undefined reference to `exynos_lot_id'

:(.text+0x517ac): undefined reference to `exynos_lot_id'

drivers/built-in.o: In function `mali_sysfs_show_asv':

:(.text+0x51ab6): undefined reference to `exynos_asv_group_get'

:(.text+0x51b2a): undefined reference to `exynos5420_is_g3d_mp6'

:(.text+0x51b50): undefined reference to `exynos_lot_id'

:(.text+0x51b58): undefined reference to `exynos_lot_id'

drivers/built-in.o: In function `mali_dvfs_event_proc':

:(.text+0x51fc8): undefined reference to `exynos_result_of_asv'

:(.text+0x51fcc): undefined reference to `exynos_result_of_asv'

make: *** [vmlinux] Error 1

Are you using the same kernel configuration that Guillaume mentioned?

./scripts/kconfig/merge_config.sh linaro/configs/linaro-base.conf linaro/configs/distribution.conf linaro/configs/arndale_octa.conf linaro/configs/lt-arndale_octa.conf linaro/configs/mali-arndale-octa.conf

Hi bramv,

Rich has been assigned onto other projects currently so will not be able to look into this for a while.

I will see if we can pick this up, but there may be a delay. I apologise for this.

Kind Regards,

Michael McGeagh