AndrewZhaoLuo opened a new issue #10294:
URL: https://github.com/apache/tvm/issues/10294


   Grouped convolutions split up input channels into groups. While a normal 
convolution consists of a stack of kernels per each channel, in grouped 
convolution a particular filter will only operate on channels in its associated 
groups. In general while a convolution with 50 input channels and 100 output 
channels might have a weight with shape `[100, 50, 3, 3]` for OIHW layout, a 
grouped convolution with `g` groups will have a weight with shape `[100, 50 / 
g, 3, 3]` where `g` must evenly divide the input channels. `g` must also divide 
the output channels (as each group should have the same number of output 
channels it is responsible for).
   
   A special case of grouped convolution is depthwise convolution where `g` is 
set to the number of input channels. The issue here is that there are two 
representations of depthwise convolution. Often times, a "depth multiplier" `d` 
is defined as the number of output channels divided by `g`. One representation 
is to have a weight with shape `[100, d, 3, 3]` where the total number of 
output channels is `100 * d`.  This is confusing because another valid 
representation is having weights with `[100, 50 / g, 3, 3]`. Furthermore this 
special representation only occurs if we hit this line of code 
https://github.com/apache/tvm/blob/be176974a03b6f7e69fee2186f3847d9c092c546/src/relay/op/nn/convolution.cc#L249.
 We can therefore have a depthwise convolution workloads with two internal 
representations. They also have seperate schedules and strategies it seems.
   
   
https://github.com/AndrewZhaoLuo/TVM-Sandbox/blob/main/relay/depthwise_convolution_inconsistency.py#L44
 shows ways of getting both representations. 
   
   This task is meant to track unifying representation of depthwise convolution 
to remove the superfluous definition with depth multipliers.
   
   TODO
   - [ ] Scope this out and what needs to be changed.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to