I think padding should be removed from Conv and Pool operators. From N2D2 experience, padding adds a lot of complexity to the operator implementations. Third party conv and pool implementations do not always support padding or all types of padding (e.g. CuDNN only supports symmetric padding).
We could have a PaddedConv meta-operator to take advantage of implementations that support padding inside conv. It could be a good first use case for meta-operator, that I will try to include in this MR.
Remove padding from operators
Add Pad implementation
Add Constant mode implementation
Handle other modes
Add PaddedConv and PaddedPooling meta-operators
Add meta-operator prototype
Requires ordered inputs for GraphView @pineapple => for now, specify ordered inputs/outputs in the meta-op
Requires generateScheduling() to be callable iteratively @cmoineau => should be OK
Update previously padded layers unit-tests
If we agree on having a separate Pad operator, I still have some questions :
Should it be one or several operators? For example, should we have a specific ZeroPad operator for 0-padding only? Or a little more general ConstantPadding for padding with a given value?
Use a single Operator.
What should be the parameters of this operators? Like constant, replicate, reflective... to handle different type of classical padding in computer vision.
Current list is Constant, Replicate, Reflect, Wrap, which are pretty standard.
