Add experimental CV-CUDA resize

[banasraf]

Category:

New feature

Description:

This PR adds new resize operator that uses CV-CUDA HQResize as its implementation.
It uses existing infrastructure of the resize operators to handle arguments and the cv-cuda op more or less replaces DALI kernel.

The testing involves extending existing tests to run the new operator in the same way the CPU and GPU versions are run.

Additional information:

Affected modules and functionalities:

New operator, small changes in ResizeBase

Key points relevant for the review:

Tests:

• Existing tests apply
• New tests added
  • Python tests
  • GTests
  • Benchmark
  • Other
• N/A

Checklist

Documentation

• Existing documentation applies
• Documentation updated
  • Docstring
  • Doxygen
  • RST
  • Jupyter
  • Other
• N/A

DALI team only

Requirements

• Implements new requirements
• Affects existing requirements
• N/A

REQ IDs: N/A

JIRA TASK: N/A

[banasraf]

!build

[dali-automaton]

CI MESSAGE: [18508010]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [18508010]: BUILD FAILED

[banasraf]

!build

[dali-automaton]

CI MESSAGE: [18511395]: BUILD STARTED

[banasraf]

!build

[dali-automaton]

CI MESSAGE: [18511556]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [18511556]: BUILD FAILED

[banasraf]

!build

[dali-automaton]

CI MESSAGE: [18512606]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [18512606]: BUILD FAILED

[banasraf]

!build

[dali-automaton]

CI MESSAGE: [18515034]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [18515034]: BUILD FAILED

[banasraf]

!build

[dali-automaton]

CI MESSAGE: [18537144]: BUILD STARTED

[banasraf]

!build

[dali-automaton]

CI MESSAGE: [18539715]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [18537144]: BUILD FAILED

[dali-automaton]

CI MESSAGE: [18539715]: BUILD PASSED

[mzient]

Why? Can't we just skip them when assembling the input/output TensorBatch?
We could do any of the following - and perhaps more:

1. store indices for each minibatch explicitlly instead of just storing the range - probably the easiest to implement;
2. have an global index array with only non-empty samples (each entry pointing to the original sample/index) - likely the most efficient option, also not hard to implement
3. we could even assemble an effective input/output TensorList and work with that (most expensive).

All options are better than giving up batched processing.

[banasraf]

Empty samples in the input are a very much edge case, I assume, so it wouldn't affect regular execution. Nevertheless, I implemented the solution with global index array

[banasraf]

!build

[dali-automaton]

CI MESSAGE: [18651120]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [18651120]: BUILD PASSED

[awolant]

Looks like it works and is tested

[szalpal]

I believe it would be good to add explicit (and extensive) info, how does fn.experimental.resize differ from fn.resize. I know user can read CV-CUDA docs and then fn.resize docs, but putting the difference in fn.experimental.resize I believe is highly accurate. Plus, I don't think there's anywhere good explanation, how does DALI resize differ from HQResize.