[onert/train] support AveragePool2D for training

[jyoungyun]

What

Let's support AveragePool2D for training.

Why?

The InceptionV3 model from TensorFlow applications has AveragePool2D operation. However, onert does not support training this operation. PoolLayer is already implemented and only supports MaxPool2D. This issue can expand the pool type to support AveragePool2D.

[icodo98]

I made a draft for this issue. #14059
PTAL 😊

[icodo98]

Here is sample model and result.
averagePool.zip

[icodo98]

from #14086 (comment)

while replacing code to use existing forwarding function, I've got a question.

for MaxPool2D in training, it's able to forward output from padding area.

ONE/compute/cker/src/train/MaxPool.test.cc

Lines 205 to 211 in 06a536b

	/**
	* input_with_padding: expected_output:
	*
	* 4 8 0 0 0
	* 9 2 -(forward)-> 0 9 0
	* 0 0 0
	*/

for average pool, I think the output will be

    /**
     * input_with_padding:             expected_output:
     *
     *    4   8                              0    0    0
     *    9   2            -(forward)->      0  5.75   0
     *                                       0    0    0
     */

But with current forwarding AveragePool function, above test case fails.

ONE/compute/cker/include/cker/operation/AveragePool.h

Lines 94 to 96 in 06a536b

	// Divide the output by the actual number of elements being averaged over
	assert(out_count.minCoeff() > 0);
	out_mat.array().rowwise() /= out_count.transpose().array();

assert(out_count >0) prevent output induced from padded layer.

So, is our policy to not induce output from padded area? or is it bug?

/cc @ragmani @zetwhite

[ragmani]

So, is our policy to not induce output from padded area? or is it bug?

It's the former. There is no case that circle model has paddings like the above test. And onert only allows padding type as "valid" and "same" for Pool ops now. The two padding types never induce Pool ops to have paddings like the above test.

[zetwhite]

And onert only allows padding type as "valid" and "same" for Pool ops now

Ah, I've had a different understanding. I thought that "explicit" type is also possible for onert Pool ops. Because while generating kernel for pool operator, KernelGenerator allows explicit pool params.

• KernelGenerator.cc, calculate padding
  

  ONE/runtime/onert/backend/train/KernelGenerator.cc

  Lines 483 to 484 in a1e9884

  	const auto padding = ir::calculatePadding(node.param().padding, ifm_shape.asFeature(),
  	ofm_shape.asFeature(), stride, kw, kh);

• calculatePadding() it allows explicit padding type
  

  ONE/runtime/onert/core/src/ir/Padding.cc

  Lines 137 to 157 in a1e9884

  	const ExplicitPadding calculatePadding(const Padding &padding, const FeatureShape &ifm_shape,
  	const FeatureShape &ofm_shape, const Stride &stride,
  	uint32_t kw, uint32_t kh, uint32_t dwf, uint32_t dhf)
  	{
  	if (padding.type == PaddingType::EXPLICIT)
  	{
  	return padding.param;
  	}
  	else if (padding.type == PaddingType::SAME)
  	{
  	return samePadding(ifm_shape, ofm_shape, stride, kw, kh, dwf, dhf);
  	}
  	else if (padding.type == PaddingType::VALID)
  	{
  	return validPadding();
  	}
  	else
  	{
  	throw std::runtime_error{"Cannot handle padding type"};
  	}
  	}

---

There is no case that circle model has paddings like the above test.

Maybe Does it mean that the frontend does not allow explicit type?

[ragmani]

Maybe Does it mean that the frontend does not allow explicit type?

I guess that training also does not allow explicit type for pool ops. As far as I know, explicit type may be allowed only in the case of pad op now.

[icodo98]

As far as I know, explicit type may be allowed only in the case of pad op now.

Then, I'll remove that test case from PR.