@monicael, does mdk device part support this feature?

@monicael, does mdk device part support this feature?

Yes. MDK side will always consider the layer params first and will check the shape of the second and third tensors only if their respective set of params are 0 (w/h for the second input, stride_x/stride_y for the third). The actual contents of the second and third tensors are never used.

@monicael should test be updated as well (add new test cases where another amount of inputs?)

@monicael should test be updated as well (add new test cases where another amount of inputs?)

I don't think that's necessary. In the example in the description, the xml still has three inputs, but the last one (which should have been the input image of the net) has a 1x1x1x1 shape and is not connected to the input of the net. I'm not sure exactly why it appears in this form, instead of missing altogether. But in the current form, the shape of one of the optional inputs doesn't matter if the associated params are not 0. So, for example, in a test where stride_x and stride_y are non-zero, it doesn't matter if the test dimensions for the third input are 1x1x1x1 or 1x3x225x225, because they will never be taken into consideration and the layer will run the same way in both cases.

@monicael should test be updated as well (add new test cases where another amount of inputs?)

I don't think that's necessary. In the example in the description, the xml still has three inputs, but the last one (which should have been the input image of the net) has a 1x1x1x1 shape and is not connected to the input of the net. I'm not sure exactly why it appears in this form, instead of missing altogether. But in the current form, the shape of one of the optional inputs doesn't matter if the associated params are not 0. So, for example, in a test where stride_x and stride_y are non-zero, it doesn't matter if the test dimensions for the third input are 1x1x1x1 or 1x3x225x225, because they will never be taken into consideration and the layer will run the same way in both cases.

Still you add new feature (optional inputs) and there is no tests for that. If there is a concern that such a case should not happen and operation always should have all inputs, so it's better to investigate the root cause rather adding this feature. I understand that in some cases values of optional inputs are ignored, but we need to check that (by writing tests). In addition, through tests it'd be clear under which circumstances some inputs may be omitted.

@monicael should test be updated as well (add new test cases where another amount of inputs?)

I don't think that's necessary. In the example in the description, the xml still has three inputs, but the last one (which should have been the input image of the net) has a 1x1x1x1 shape and is not connected to the input of the net. I'm not sure exactly why it appears in this form, instead of missing altogether. But in the current form, the shape of one of the optional inputs doesn't matter if the associated params are not 0. So, for example, in a test where stride_x and stride_y are non-zero, it doesn't matter if the test dimensions for the third input are 1x1x1x1 or 1x3x225x225, because they will never be taken into consideration and the layer will run the same way in both cases.

Still you add new feature (optional inputs) and there is no tests for that. If there is a concern that such a case should not happen and operation always should have all inputs, so it's better to investigate the root cause rather adding this feature. I understand that in some cases values of optional inputs are ignored, but we need to check that (by writing tests). In addition, through tests it'd be clear under which circumstances some inputs may be omitted.

Alright, that makes sense. I'll write tests for the optional input cases and will let you know when they're done :)