OpenCL support for Mali-T628 MP6 on Arndale Octa?

Hi Chris,

Where can we find benchmark numbers for examples kernels provided with SDK?. We ran "sobel" filter example for 1024x1024 image, profile number measured across kernel trigger and wait measures as 5msec. And Laplace transform for 4096x2048 image, number measures as 10msec. Is these numbers expected for for Mali T628 @ 533Mhz GPU? We measured the numbered across clEnqueueNDRange() and immediate clFinish().

Thanks,

Veeranna

Hi Veerannah,

We don't have stock performance numbers for the SDK samples to hand.  However what I will do later this week is run Sobel and Laplace on a platform here and get some numbers back to you.

HTH, Tim

Hi Tim,

We really appreciate your quick reply. Looking forward to see the performance numbers.

Thanks,

Veeranna

Hi Veeranna,

I ran the Sobel filter as provided by the Mali OpenCL SDK, modifying it to run a 1024x1024 image and I see the following...

Queued time:    0.11ms

Wait time:        0.222292ms

Run time:         0.680683ms

The Mali OpenCL SDK doesn't include a Laplace transform... which one are you using?

Best regards, Tim

Hi Veeranna,

I realise I didn't include the platform details.  I'm running on a Mali-T604 platform with the GPU clocked @ 533MHz.  I'm using a later version of the drivers than you, I believe, and that would likely mean the performance you would expect on your platform is slightly worse.  On balance though I would expect the performance on your Mali-T628 system to be roughly equivalent to mine.

HTH, Tim

Hi Tim,

Thank you for providing information on performance number. With "cl_event" profiling we are getting numbers as

Queued time:    0.11ms

Wait time:        0.2725ms

Run time:         0.7586ms

But if we measure numbers across clEnqueueNDRangeKernel() and clfinish() using gettimeofday we are seeing number is 1.5msec. Is this API/driver overhead?

Thanks,

Veeranna

Hi Veeranna,

Is this API/driver overhead?

Probably, yes.  When I try this I'm seeing the same sort of additional time using gettimeofday vs the profiling values output.  With the Sobel sample I looked at the difference in this additional time when I increased the size of the image being processed.  It appeared to stay roughly the same, which would back up the theory that this is due to additional overhead in the API.

Hope that helps,

Tim

Thank you for the information.

I cannot stress enough that if you are interested in real world performance, you should move away from these synthetic benchmarks and look at actual data for proper use cases. There are some real-world oriented benchmarks out there already, which already have Mali powered devices in their results.

I totally agree that synthetic benchmarks are no proper measure for real world performance, but these benchmarks do help to determine whether the environment is set-up properly, which is clearly not (yet) the case.

Have spoken to someone from the driver team, if you're only seeing one device then it must be an old driver, it's worth asking Insignal what their roadmap is for providing updates. On current drivers you will see 2 devices, one with 4 cores and one with 2.

By now the r4p0-02rel0 drivers are available. I tried running the benchmarks using them instead of the r3p0-02rel0 drivers that I used before, however the runtime fails to create an OpenCL context.

Someone opened a topic on the Insignal forum about the latest drivers, it seems that I have to compile my own kernel using the latest kernel driver to get it working.

Hi Bram,

Yes thats correct the old kernel driver will not work with the new userspace driver, the kernel needs recompiling with the new kernel driver.

Hth,

Chris

Hi Bramv,

Are you able use all 6 cores T628?. If you are succeeded can you give complete steps to builds required  binaries.

Thanks,

Veeranna

Hi Bramv,

/dev/mali should show as soon as you insmod a correctly built Mali kernel module.  If /dev/mali is not appearing then the kernel module is not correctly built and configured for the platform.  Even if you successfully build and insert a correct kernel module for the platform userspace functionality, such as OpenCL, will not be available without Mali userspace binaries matching the version of the Mali kernel module.

Can you confirm the kernel you are trying to compile with/against and the versions of Mali kernel and userspace you have available to you, as ARM have only currently released the r4p0 userspace binaries, though r4p1 should be available through the malideveloper site in the not too distant future.

Could you also confirm the steps you have taken to configure the Mali kernel source for use with the Arndale Octa board, especially as I can see you are trying to build it out of tree?  You need to configure the kernel device tree and add platform specific configuration to the kernel to set up interrupts and memory addresses etc.  The easiest way to integrate the latest version of the kernel would be to download the Linaro kernel for Arndale Octa and extract the r4p1 kernel source INTO the kernel source, overwriting the included r4p0 kernel source as this will keep the platform integration files intact.  Looking at the kernel source you mentioned in your earlier post "II-arndale-octa" I can see that the platform integration files are present, for example in /drivers/gpu/arm/midgard/platform/5420.  You could try extracting the r4p1 kernel source into this kernel tree and building that way.

Hope this helps,

Rich

Hi Rich,

In fact, I didn't configure anything at all but just ran:

CONFIG_MALI_MIDGARD=m make

And ended up with this module for the r4p1 kernel driver:

filename:       /lib/modules/3.15.0-1-linaro-arndale-octa/kernel/drivers/gpu/arm/midgard/mali_kbase.ko

version:        r4p1-00rel0

license:        GPL

srcversion:     29BCA495EB0E26992A9C01E

alias:          of:N*T*Carm,mali-midgard*

alias:          of:N*T*Carm,malit6xx*

depends:       

vermagic:       3.15.0-1-linaro-arndale-octa SMP mod_unload ARMv7 p2v8

And this one for r4p0:

filename:       /lib/modules/3.15.0-1-linaro-arndale-octa/kernel/drivers/gpu/arm/midgard/mali_kbase.ko

version:        r4p1-00rel0

license:        GPL

srcversion:     29BCA495EB0E26992A9C01E

alias:          of:N*T*Carm,mali-midgard*

alias:          of:N*T*Carm,malit6xx*

depends:       

vermagic:       3.15.0-1-linaro-arndale-octa SMP mod_unload ARMv7 p2v8

Next I downloaded the following kernel: linux-linaro-3.15-2014.06, because it seems to be the closest match to the running kernel: 3.15.0-1-linaro-arndale-octa. I enabled the Mali options in the kernel configuration:

Enable Mali GPU support in Gator

-Mali-400MP or Mali-450MP

+Mali-T604 or Mali-T658

Path to Mali driver: drivers/gpu/arm/midgard

To do so I had to enable some timers and performance events options as well. The path points to the r4p0 driver that I copied into the kernel tree. Why does the configuration option only mention T604 and T658, and not T628?

After running "make modules" I had once again a mali_kbase.ko, but the result is the same as for the out-of-tree build: no /dev/mail.

The next step was to build and flash the full kernel. Apparently the kernel I used is not fully compatible since the -arndale-octa postfix is missing. As a result I had to modify some filenames to get the new kernel installed. Unfortunately this didn't work, the board does not boot any more. I have been looking for the proper linaro arndale-octa kernel source so that I can try it again, but haven't found it yet since it appears that only the binary hwpack and rootfs are available. Will be continued.