For Mali T604 and T628, peak performance is 17 FP32 FLOPS per ALU per cycle.http://malideveloper.arm.com/downloads/OpenCL_FAQ.pdf shows this is compsed of:
And also in What is exact double precision performance for Mali T628 MP6 (Arndale Octa Board) ? , @chrisvarns says 17flops.
And in http://malideveloper.arm.com/downloads/IWOCL.pdf, timhar01 also says 17flops.
But according to my measurement, it can't process dot product with vec4 MAD together. The running time of case 1 and case 2 is the same. Why? How can I get 17 flops?
case 1:
" color_out5 = color_out5*color5+color6;\n"
case2:
" color_out1 = vec4(dot(color_out1, color1));\n"
Hi chen,
I can't talk publicly about the hardware internals at this level unfortunately, but suffice to say, the performance of a particular shader is completely dependent on the way that shader is written, and how it maps to/schedules on a particular architecture. It is not expected that all code will execute at the peak theoretical throughput, so you should not worry about achieving this target in practice. Best practice advice for writing shaders for Mali GPUs can be found in the Optimization Guide available at Mali GPU Application Optimization Guide v3.0 « Mali Developer Center, and this is the bulk of the public information on the subject of optimization for Mali GPUs.
Hope this helps,
Chris
P.S. In case anyone is interested, in the following shader I have modified my previous shader to use mediump, and now contains a total of 132 fp16 operations (120 for the 8x DOT, MUL, and ADD, and 12 for the final 2 MUL and 1 ADD necessary to stop the compiler optimizing everything out):
precision mediump float; varying vec4 color5; varying vec4 color6; varying vec4 color1; vec4 color_out5a; vec4 color_out1a; vec4 tmpa; vec4 color_out5b; vec4 color_out1b; vec4 tmpb; void main(void) { color_out5a = color5; color_out1a = color1; color_out5b = color5; color_out1b = color1; tmpa = vec4(dot(color_out5a, color1)); color_out5a = tmpa * color_out5a; color_out1a = tmpa + color_out1a; tmpb = vec4(dot(color_out5b, color1)); color_out5b = tmpb * color_out5b; color_out1b = tmpb + color_out1b; tmpa = vec4(dot(color_out5a, color1)); color_out5a = tmpa * color_out5a; color_out1a = tmpa + color_out1a; tmpb = vec4(dot(color_out5b, color1)); color_out5b = tmpb * color_out5b; color_out1b = tmpb + color_out1b; tmpa = vec4(dot(color_out5a, color1)); color_out5a = tmpa * color_out5a; color_out1a = tmpa + color_out1a; tmpb = vec4(dot(color_out5b, color1)); color_out5b = tmpb * color_out5b; color_out1b = tmpb + color_out1b; tmpa = vec4(dot(color_out5a, color1)); color_out5a = tmpa * color_out5a; color_out1a = tmpa + color_out1a; tmpb = vec4(dot(color_out5b, color1)); color_out5b = tmpb * color_out5b; color_out1b = tmpb + color_out1b; gl_FragColor = color_out1a * color_out5a + color_out1b * color_out5b; }
Shader compiler output:
varnz@soma:/raid/scratch/forum-19453$ Mali_Offline_Compiler_v4.2.0/malisc -f -V -c Mali-T620 -r r1p0 -d Mali-T600_r3p0-00rel0 case4.frag -o case4.r3p0.bin ARM Mali Offline Shader Compiler v4.2.0 (C) Copyright 2007-2014 ARM Limited. All rights reserved. Compilation successful. 2 work registers used, 0 uniform registers used, spilling not used. A L/S T Total Bound Cycles: 6 1 0 7 A Shortest Path: 2 1 0 3 A Longest Path: 2 1 0 3 A Note: The cycles counts do not include possible stalls due to cache misses. Output binary written to 'case4.r3p0.bin'.
varnz@soma:/raid/scratch/forum-19453$ Mali_Offline_Compiler_v4.2.0/malisc -f -V -c Mali-T620 -r r1p0 -d Mali-T600_r3p0-00rel0 case4.frag -o case4.r3p0.bin
ARM Mali Offline Shader Compiler v4.2.0
(C) Copyright 2007-2014 ARM Limited.
All rights reserved.
Compilation successful.
2 work registers used, 0 uniform registers used, spilling not used.
A L/S T Total Bound
Cycles: 6 1 0 7 A
Shortest Path: 2 1 0 3 A
Longest Path: 2 1 0 3 A
Note: The cycles counts do not include possible stalls due to cache misses.
Output binary written to 'case4.r3p0.bin'.
so that totals 33 FLOPS/cycle/ALU! Also it's one less cycle in the L/S pipe, which is nice.
Hi chrisvarns,
Thanks for your reply. It's really helpful.
I find a strange thing. If I modify your code, change precision from mediump to highp, the cycles is also 6...
precision highp float; varying vec4 color5; varying vec4 color6; varying vec4 color1; vec4 color_out5a; vec4 color_out1a; vec4 tmpa; vec4 color_out5b; vec4 color_out1b; vec4 tmpb; void main(void) { color_out5a = color5; color_out1a = color1; color_out5b = color5; color_out1b = color1; tmpa = vec4(dot(color_out5a, color1)); color_out5a = tmpa * color_out5a; color_out1a = tmpa + color_out1a; tmpb = vec4(dot(color_out5b, color1)); color_out5b = tmpb * color_out5b; color_out1b = tmpb + color_out1b; tmpa = vec4(dot(color_out5a, color1)); color_out5a = tmpa * color_out5a; color_out1a = tmpa + color_out1a; tmpb = vec4(dot(color_out5b, color1)); color_out5b = tmpb * color_out5b; color_out1b = tmpb + color_out1b; tmpa = vec4(dot(color_out5a, color1)); color_out5a = tmpa * color_out5a; color_out1a = tmpa + color_out1a; tmpb = vec4(dot(color_out5b, color1)); color_out5b = tmpb * color_out5b; color_out1b = tmpb + color_out1b; tmpa = vec4(dot(color_out5a, color1)); color_out5a = tmpa * color_out5a; color_out1a = tmpa + color_out1a; tmpb = vec4(dot(color_out5b, color1)); color_out5b = tmpb * color_out5b; color_out1b = tmpb + color_out1b; gl_FragColor = color_out1a * color_out5a + color_out1b * color_out5b; }
And when I change the input, the cycles doubles...
precision mediump float; varying vec4 color5; varying vec4 color6; varying vec4 color1; varying vec4 color2; varying vec4 color3; vec4 color_out5a; vec4 color_out1a; vec4 tmpa; vec4 color_out5b; vec4 color_out1b; vec4 tmpb; void main(void) { color_out5a = color5; color_out1a = color1; color_out5b = color2; color_out1b = color3; tmpa = vec4(dot(color_out5a, color1)); color_out5a = tmpa * color_out5a; color_out1a = tmpa + color_out1a; tmpb = vec4(dot(color_out5b, color1)); color_out5b = tmpb * color_out5b; color_out1b = tmpb + color_out1b; tmpa = vec4(dot(color_out5a, color1)); color_out5a = tmpa * color_out5a; color_out1a = tmpa + color_out1a; tmpb = vec4(dot(color_out5b, color1)); color_out5b = tmpb * color_out5b; color_out1b = tmpb + color_out1b; tmpa = vec4(dot(color_out5a, color1)); color_out5a = tmpa * color_out5a; color_out1a = tmpa + color_out1a; tmpb = vec4(dot(color_out5b, color1)); color_out5b = tmpb * color_out5b; color_out1b = tmpb + color_out1b; tmpa = vec4(dot(color_out5a, color1)); color_out5a = tmpa * color_out5a; color_out1a = tmpa + color_out1a; tmpb = vec4(dot(color_out5b, color1)); color_out5b = tmpb * color_out5b; color_out1b = tmpb + color_out1b; gl_FragColor = color_out1a * color_out5a + color_out1b * color_out5b; }
So I think your code is somehow optimized.
According to peterharris's answer in the thread How many gigaflops GPU MALI T624 MP6 reaches?,
"Most graphics content heavily uses fp16 rather than fp32 - for Mali this means we can get (approximately) double the performance in terms of peak FP16 flops throughput". That means we can get double peak throughput.
How can we get that throughput?
The number of floating point operations that the vector units can perform is double for FP16, than it is for FP32, resulting in double PEAK FLOPS for those units. But again, this is PEAK and we are not trying to suggest that you should expect this level of performance with every shader. The shader above is a bad example of the effect on A pipe instructions apparently as in that case it is only affecting the number of load/store instructions (still a good optimization!). General advice is to use mediump wherever possible, as this gives the compiler the most chance of taking advantage of it.
Thanks,