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.
Hi bramv,
The Mali-T628 GPU supports OpenCL, absolutely, and we support this in the drivers for that GPU which we ship to our silicon customers when they licence the GPU design. The userspace drivers that you have downloaded from malideveloper.arm.com require a kernel driver integration in order to work.
If /dev/mali0 does not exist on your platform then the mali kernel driver that exposes this device has not been integrated with the kernel you are using. I believe Linaro kernels do not currently support Mali so this is expected to not be available on those kernels. You either need to integrate the kernel module with the Linaro kernel, lobby Linaro to support Mali in their kernel (would be a long term solution, don't know why they don't do this currently), or use the Insignal kernel which should support it. Yoshi is almost certainly not using a Linaro kernel, and is using one probably from Insignal which has the mali kernel module integrated.
Hope this helps,
Chris
The person who does the work to enable Mali kernel drivers with Linaro kernels will just be getting an Arndale Octa board this week. We will have a kernel git tree, hwpack and user space file systems path for install soon.
Git if you want to build your own kernel.
hwpack + user space file system if you just want to install and go.
I'll post links as they become ready.
Why doesn't Linaro have Mali support by default in it's kernels? Well first and foremost is that the Mali kernel driver isn't upstream so when you have a "new" board like Octa we have to add the Mali drivers into the bring up kernel tree, test and so on. The support for the Arndale Octa board isn't even all upstream yet.
There is indeed no /dev/mali0 on my platform. I tried compiling and installing this kernel driver to fix it, but this hasn't been successful so far. The same holds for the Insignal kernel, I didn't manage to replace the Linaro kernel with that one. The main problem seems to be that I cannot get uboot to actually boot the freshly compiled kernel.
That is great news! In that case I think I will just wait for that person to release a hwpack + file system so that I can just flash that one on an sd-card and start using OpenCL!
I have successfully compiled linaro kernel with basic support for Mali drivers. The device node /dev/mali0 is available and gles operations seem to work, but it has very low frame rate and only a working userspace drivers for mali t628 will fix it. I haven't checked if opencl works and will do so when I have some free time.
Details: Start with linaro image at Linaro Releases
You can now use the kernel, initrd images and board dtbs from http://livehopper.com/boot.tar to have mali device node (version r3p0). You will need to copy the binaries to the boot partition: /dev/mmcblk1p2
Or, you can use the kernel sources at abhijeet-dev/ll-arndale-octa · GitHub - branch linux-linaro is based on linux 3.15 rc5 and linux-linaro-old on 3.14. Build and install instructions are available in build.txt for building on the board.
Mali r3p0 userspace binaries work with the release, though you can enable support for r4p0 while building the sources if you have access to userspace binaries for r4p0 (for mali T628).
I have tried the boot files and can confirm that OpenGL is indeed working. OpenCL however doesn't and results in errors:
[ 190.070000] Mali<ERROR, BASE_MMU>: kbase_mmu_report_fault_and_kill Unhandled Page fault in AS0 at VA 0x00000000B6ED2100
[ 190.070000] raw fault status 0x820003C3
[ 190.070000] decoded fault status: SLAVE FAULT
[ 190.070000] exception type 0xC3: TRANSLATION_FAULT
[ 190.070000] access type 0x3: WRITE
[ 190.070000] source id 0x8200
[ 190.090000] Mali<ERROR, BASE_JM>: kbase_job_done_slot t6xx: GPU fault 0x43 from job slot 1
Can I conclude that it is just a matter of waiting for the r4p0 userspace binaries to become available?
I don't think that's userspace related, it's more likely to be a problem with the kernel integration. Interesting that it only happens with CL. Can you reproduce that with one of the simple samples from our CL SDK? https://developer.arm.com/products/software/mali-sdks Thanks,
Hi Chris,
We also want to use T628 for opencl computations on Exynos5420, But our SOC has Android as OS. Can you please help us to find the opencl driver for android? OR we have to get the source and compile?
PS: If you feel my post will divert the original post's intention I can raise new post.
Thanks,
Veeranna
Hi Veeranna,
The driver is composed of 2 parts, kernel, and userspace binaries. The kernel space source code is open source and available from the link you posted, and that will need integrating into the kernel for your SoC, which is more than likely already done by your specific SoC/board/device vendor. What board/device are you using? If you're using a kernel other than the ones provided by the device/SoC/board vendor, then you will likely need to do this yourself.
Once that's done, you will need the matching userspace binary. We currently provide r3p0-02rel0 binaries for Linux (provided as part of the Chromebook guide), and an r4p0 release is coming very soon (currently stalled in legal review). We do not however currently offer any Android userspace binaries for any devices/boards, nor do we currently have any plans to, so these would need to come from your SoC/device/board vendor.
Thanks for the reply Chris,
We are using Exynos 5420 board from Insignal. Yes it has kernel level binary inside the device. Getting a driver at Android usespace will be very helpful, because we run our application on different vendor SOCs to compare the performance. The other SOCs we have has Android as the OS.
I will check in Insignal forums.
Thanks for your help.
I got the driver from Samsung/Insignal, and able to build the Andorid Image and Run. But we are observing random behavior in OpenCL APIs. Some time clcreateKernel fails and if re-run the app clcreateKernel returns success but clcreatebuffer fails with error code as zero and returned memory pointer as NULL.
Can you give some to hint where to look.
Can you provide us with a simple reproducer? Also please let me know the driver version you're using, with adb pull /vendor/lib/egl/libGLES_mali.so && strings libGLES_mali.so | grep r[0-9]p[0-9] assuming it's in vendor and not system.
With above said command, I got version as 1.4 Midgard-"r3p0-01bet0. I will try to give simple app to run.
Thank you for help.
Interestingly simple median filter example runs fine(openCL on T628), but our application fails. Our application has many kernels and huge memory bandwidth will it be the reason?
Any suggestion for debugging will be helpful.
Hi veerannah,
I doubt simply having a lot of kernels would in itself be a problem, nor would I expect memory bandwidth to be an issue. Can you confirm whether you are creating all of your kernels up-front before any clEnqueueNDRange commands take place, or do you somewhat interleave kernel compilation and execution? Can you also confirm whether all program objects compile without error prior to the calls to clCreateKernel that consume them?
We create all our kernels first, then we allocate required buffers and then call clEnqueueNDRange. Sometime it fails to create some kernels(some are got created). And sometimes it fails in buffer allocation. It didnt hit clEnqueueNDRange yet.