feat: support aten.resize_ converter

[chohk88]

Description

Support converter for aten.resize_ operation: https://pytorch.org/docs/stable/generated/torch.Tensor.resize_.html#torch.Tensor.resize_

One critical aspect of this operation is handling cases where the target size (output size) is larger than the input tensor size. When the target size is larger than the input tensor size, the values of the additional elements are unpredictable. In PyTorch, these additional elements are not initialized, which can result in values that are close to zero but are not guaranteed to be zero.

In the converter developed for this PR, the additional elements are initialized to zero using numpy.zeros. While this approach ensures a predictable output, it does not exactly replicate the behavior of PyTorch, where the values of the additional elements are not initialized and can be unpredictable.

Fixes # (issue)

Type of change

• New feature (non-breaking change which adds functionality)

Checklist:

• My code follows the style guidelines of this project (You can use the linters)
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas and hacks
• I have made corresponding changes to the documentation
• I have added tests to verify my fix or my feature
• New and existing unit tests pass locally with my changes
• I have added the relevant labels to my PR in so that relevant reviewers are notified

[zewenli98]

Overall looks good, just left some comments for your reference.

Although the additional elements are unpredictable but they are close enough to zero, as you said, I think it is able to pass our checkpoints since the tolerance is acceptable

[chohk88]

@apbose @zewenli98 The converter for resize_ has been fully implemented functionally.

However, while investigating the cause of the CI/CD failure, I found that tensors in uninitialized locations sometimes contain extremely large values, whereas the description always showed values very close to zero (in the range of 10^-40) or zero. Do you have any suggestions on how to handle tests in such cases?

[narendasan]

Use run_tests custom compare and check the original elements and the shape to verify correctness

[apbose]

@chohk88 I was talking about the function run_test_custom_compare_results(). You can implement the attributes of the TRTTensor and the ref Tensor which you would want to compare in the comparators arg.

[apbose]

Is there a specific case where the len(cuda_inputs) == 1 is required? In general I assume the len(cuda_inputs) would be 1 in most cases. And since it conditioned on res_trt could you highlight the cases where it would be required?

[chohk88]

Thank you for your comment!

As you mentioned, in most cases, the length of cuda_inputs is 1. Below are the outputs when I set a breakpoint in the original code for two cases where torch.ops.aten.resize_.default(x, target_shape) returns tensors with shapes (3,) and (10, 15, 10).

In both cases, the length of cuda_inputs is also 1. When cuda_inputs has a length of 1, res_trt and res_cpu are not lists of length 1 but are torch.Tensors with shapes (3,) and (10, 15, 10) for each case. Therefore, when we use zip in for output_trt, output_cpu, comparator in zip(res_trt, res_cpu, comparators), and the comparators list has a length of 1, it results in comparing fewer elements because one dimension is lost from res_trt and res_cpu.