The converged pad and convolution NPU are not supported about ethos-n-driver-stack

[eleanor-arm]

Hi xiaoyu1004,

thank you for your question. Could you please provide us with your input/output tensor sizes if the convolution you're running?

Thanks,
Eleanor

[xiaoyu1004]

The pad and convolution in the picture are fused during grath optimization, and NPU does not support it. The input size of pad is 1 x 320 x 320 x 32.

[eleanor-arm]

Hi xiaoyu1004,

Looking at the input, kernel sizes and striding you provided it seems that some of the padding will not be used. The driver stack checks for that so that might be the reason why the convolution comes out as unsupported together with the padding.

The solution might be to remove the padding on the right and bottom.

Let us know if that helps,
Eleanor

[xiaoyu1004]

Hi xiaoyu1004,

Looking at the input, kernel sizes and striding you provided it seems that some of the padding will not be used. The driver stack checks for that so that might be the reason why the convolution comes out as unsupported together with the padding.

The solution might be to remove the padding on the right and bottom.

Let us know if that helps, Eleanor

Shouldn't you remove the left and top pad? tensorflow's SAME pattern is on the right and bottom. We don't know how armnn works, right

[eleanor-arm]

Either way should work. We think that the issue is caused by a check that only checks whether all the padding is used considering tensor sizes. Removing padding from top and left to avoid superfluous padding should work too.

[eleanor-arm]

xiaoyu1004 Are you happy with the answer?

[xiaoyu1004]

Why do the operators in the figure above have different results on Arm CPU and NPU？

[eleanor-arm]

Hi xiaoyu1004,

Thank you for sending the image. Could you please elaborate on your question a bit? Where do you see the difference between CPU and NPU?

[xiaoyu1004]

Hi xiaoyu1004,

Thank you for sending the image. Could you please elaborate on your question a bit? Where do you see the difference between CPU and NPU?

I calculated the Euclidean distance between the CPU and the NPU result and found that the convolution of the same pattern was different.

[eleanor-arm]

Hi xiaoyu1004,

Could you please also share how you're getting these results? Are you using SPA, or running on an FPGA?

Thank you

[xiaoyu1004]

Hi xiaoyu1004,

Could you please also share how you're getting these results? Are you using SPA, or running on an FPGA?

Thank you

I am comparing the last output of the network on CPU and NPU，After debugging the latest results, we found that it is not because of the convolution SAME mode, but because of the error in the calculation of the resize bilinear interpolation. The RESIZE nearest neighbor interpolation has no problem, while the bilinear interpolation NPU calculation has problems. The test network structure is as follows:

[eleanor-arm]

Hi xiaoyu1004,

We suspect this is a bug in the current version of the software and planned to get this fixed in the 22.08 release.

[xiaoyu1004]

Hi xiaoyu1004,

We suspect this is a bug in the current version of the software and planned to get this fixed in the 22.08 release.

Ok, thank you. I want to know when will 22.08 be released?

[eleanor-arm]

Hello xiaoyu1004,

Please accept an update to my previous message.
RESIZE bilinear with align_corners=false and half_pixel_centers=true is currently only supported with reduced accuracy due to hardware limitations. Resize in other configuration is possible without a loss in accuracy. We are planning to update the documentation to reflect this soon.

Despite this loss of accuracy in the resize layer, is the overall accuracy of your network acceptable?

[xiaoyu1004]

Hello xiaoyu1004,

Please accept an update to my previous message. RESIZE bilinear with align_corners=false and half_pixel_centers=true is currently only supported with reduced accuracy due to hardware limitations. Resize in other configuration is possible without a loss in accuracy. We are planning to update the documentation to reflect this soon.

Despite this loss of accuracy in the resize layer, is the overall accuracy of your network acceptable?
Ok, thank you. I tried other configurations, but the result of resize with reduced accuracy is unacceptable

[jslater8]

I see that the test network has half_pixel_centers set to true. It should be more accurate if that is turned off. Would that be a possibility for you to try?