OpenCL support for Mali-T628 MP6 on Arndale Octa?

Hi Chris,

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.

Thanks,

Veeranna

It's interesting that its not deterministic where it fails. Without a reproducer I'm afraid I'm just guessing at possible causes. Also the driver itself is quite old now, we're currently at r4p0, so it is worth asking them when they plan to provide an up to date version as this could fix it.

Thanks,

Chris

I tried the SGEMM sample from the SDK:

root@arndale-octa:~/Mali_OpenCL_SDK_v1.1.0/samples/sgemm# ./sgemm

[PLUGIN INFO] Plugin initializing

[PLUGIN DEBUG]  './override.instr_config' not found, trying to open the process config file

[PLUGIN DEBUG]  './sgemm.instr_config' not found, trying to open the default config file

[PLUGIN ERROR] Couldn't open default config file './default.instr_config'.

[PLUGIN INFO] No configuration file found, attempting to use environment

[PLUGIN INFO] CINSTR GENERAL: Output directory set to: .

[PLUGIN INFO] No instrumentation features requested.

^C[  384.380000] Mali<ERROR, BASE_MMU>: kbase_mmu_report_fault_and_kill Unhandled Page fault in AS0 at VA 0x00000000B6F0E100

[  384.380000] raw fault status 0x820003C3

[  384.380000] decoded fault status: SLAVE FAULT

[  384.380000] exception type 0xC3: TRANSLATION_FAULT

[  384.380000] access type 0x3: WRITE

[  384.380000] source id 0x8200

[  384.400000] Mali<ERROR, BASE_JM>: kbase_job_done_slot t6xx: GPU fault 0x43 from job slot 1

The program hangs after the [PLUGIN INFO] messages are printed. When I press ctrl+c, the kernel messages appear, indicating that the GPU run into trouble?

That looks like an integration problem to me, it's worth reporting to Linaro, as I believe that's the kernel you're using?

Hope this helps,

Chris

Hi Chris,

Finally we are able to run our application on T628. But performance numbers are not good. Do we get any improvement if we move r4p0 driver?

Any other suggestions to improve the GPU performance will be helpful.

Thanks,

Veeranna

Hi Bramv,

At the risk of beating a dead horse, by my math the peak throughput of the Mali T628 MP6 in the Arndale Octa is:

17 FLOPS * 2 ALUs per core * 6 cores * 0.533Ghz (i think this is the max frequency for this board?) = 108.732 GFLOPS. But, as those cores are distributed across 2 core groups (4+2) simply using the first device available will mean you're only running on 4 cores, so that comes down to 72.488GFLOPS. That's the peak possible throughput of the A pipes, if you were to just keep pumping instructions through it which perfectly exercise all the functional units. In the real world, where kernels tend not to map perfectly to the hardware, tend to include some LS activity, tends to try and load stuff not in the cache, bandwidth is finite etc, it is not expected that you will actually achieve this in real world use cases. Asking for peak flops is the wrong question if you're really interested in peak real world performance.

I am seeing 33.27 and 33.17 SP GFLOPS for float2 and float4 respectively, or 45% of max theoretical peak (this is very good, considering its probably just using the VMUL and VADD units, havent looked into it yet), without looking at the actual code of the benchmark, which seems to indicate your environment has some issue. I will investigate why this benchmark reports almost identical perf numbers for float2 and float4. I also have to state that I've never seen clpeak before and am in no way vouching for its accuracy or usefulness when comparing GPU products.

Hth,

Chris

UPDATE: I've taken a look at the kernels and sure enough apart from right at the end they only touch the VMUL and VADD units. The workload is purely vector add and multiply, and absolutely does not touch the scalar or dot units, so you can take that 17 FLOPS down to 8, and our peak realistic performance becomes:

8 FLOPS * 2 ALUs * 4 cores (in one core group, which is 1 CL device) * 0.533 = 34.112 GFLOPS peak realistic performance.

We're seeing 33.27 GFLOPS, which is 97.5% of peak realistic performance, so not too shabby.

Hi Chris, I am glad that you did reply, you bring up some very interesting topics!

For me only one OpenCL platform containing only one device is found and when I request the number of compute units and clock frequency:

cl::Device device

device.getInfo<CL_DEVICE_MAX_COMPUTE_UNITS>();

device.getInfo<CL_DEVICE_MAX_CLOCK_FREQUENCY>()

I get 6 and 600 respectively. So I would assume that I am running on all six cores at 600 Mhz. Is there anything I can do to verify which core group is actually used?

Somewhere else mentioned the following formula for peak floating points performance:

16FP x 2 Vec4 x 6 Clusters x 0.600 GHz = 115.2 GFLOPS

Here the number of flops is 16 instead of 17, so I wonder where those numbers come from. Is there any reference document (by Mali?) that lists all important specs, like the number of FLOPS (including the exact number of vector, scalar and dot units per compute unit?

I ran clpeak on another architecture (Nvidia Tesla K40) and the program indeed measured peak performance (of about 4000 GFLOPS), therefore I assumed that I could also use this benchmark to measure peak performance of this Mali GPU. SInce this clearly doesn't work, I wonder how if I we could come up with some kernel that runs at +/- 100 GFLOPS. What benchmark are you using to measure those 33.27 GFLOPS?

You might be wondering why I am so determined to run the GPU at peak performance, but that is to ultimately be able to directly compare the efficiency of this presumably energy-efficient GPU to more common accelerators like the Nvidia Tesla K40, AMD Firepro W9100 and Intel Xeon Phi.

Hi Bramv,

I get 6 and 600 respectively. So I would assume that I am running on all six cores at 600 Mhz. Is there anything I can do to verify which core group is actually used?

Just to add to what Chris has said about this, this is indeed what we see with older versions of the driver.  As you are seeing, with this version it does return 6 cores, though it really will only run on 4 of them.  This particular SoC configures the 6 cores into 2 core-groups, 4 + 2.  With the driver version you are using you can only target the 4-core group with CL... it is only later drivers that allow access to both core groups, and then it will be as separate devices so you will need to manually split the work if you want to use all the cores.  (Graphics works differently and can automatically spread the workload across the entire GPU).

Hope that helps, Tim