Summary
Is OpenCL support for the Mali-T628 (for example as found in the Exynos 5420 SoC on the Arndale Octa board) available? If so, how to set it up?
More details
According to the vendor, OpenCL should be supported, but the Arndale Octa Wiki does not state how this can be achieved.
I am using the latest Linaro developer build and installed Mali drivers that contain OpenCL libraries for Mali T604. According to this guide, the driver actually contains references to the Mali T628. So I tried to create the udev rule as specified, which is supposed to solve a permission problem with /dev/mali0, but I found that there is no /dev/mali0 on my installation at all. So my conclusion is that the driver indeed does not support T628.
When I execute a clinfo utility, clGetDeviceInfo returns CL_OUT_OF_HOST_MEMORY for some device properties. Why can I query the GPU for some characteristics, but does this fail for some others? When running a normal application, the same error appears when trying to create an OpenCL Context.
I was surprised to find this topic, where yoshi seems to have OpenCL working and can run benchmarks on his Arndale Octa board. How is this possible if there is no driver available? Or am I just missing something? I hope that you can help me to also establish a working OpenCL development environment.
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
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?
Hi Bramv,
Taken shamelessly from an answer by peterharris in another thread:
"The DVFS code for the GPU is not directly managed by our drivers - it is part of the platform integration provided in the BSP from Insignal. This style of integration occurs because the DVFS analogue parts which control F and V for the power domains are not part of the ARM IP. This question is probably best asked to Samsung or Insignal, as they maintain the BSP for that platform."
It is possible to disable features such as DVFS by recompiling the linux kernel and mali kernel module with the correct configuration. The reason this reduced performance (normally) happens is because DVFS ties the GPU frequencies to the workload of the CPU. As you are running your intensive GPU test, the CPU is left to idle and so DVFS drops the CPU core speed, unfortunately, also dropping the GPU frequency.
A means of stopping this happening would be to add some CPU intensive code to run whilst the GPU code is running to stop DVFS dropping the frequencies.
Hope this Helps,
Rich