Support CPU samples in predefined automatic augmentations #4772
Conversation
| sample : DataNode | ||
| A batch of samples to be processed. The samples should be images of `HWC` layout, | ||
| `uint8` type and reside on GPU. | ||
| shapes: DataNode, optional | ||
| `uint8` type. | ||
| shape: DataNode, optional |
There was a problem hiding this comment.
Nitpick: I'd rather use data / shape or samples / shapes - calling a batch of samples sample seems to be going a step too far.
There was a problem hiding this comment.
On the one hand, it might be a bit controversial, on the other, it just fits the "sample" oriented style of DALI pipelines (maybe apart from manual/external source feeding of the inputs). You write the pipeline as if in terms of samples, but it produces batches. I am also reluctant to chaning the parameter name, as we already released this module, it would be kind of a breaking change.
There was a problem hiding this comment.
But you did change the other - I know it's optional, but isn't the first argument positional anyway?
There was a problem hiding this comment.
The change is only in the docs - I've mistekenly used plural in the docs, the actual argument name is shape.
There was a problem hiding this comment.
Btw. I apparently fixed that typo in #4753, after rebasing it dissapeared here.
| (True, False))))) | ||
| @params(*tuple( | ||
| enumerate( | ||
| itertools.product(("cpu", "gpu"), (True, False), (True, False), (None, 0), (True, False))))) |
There was a problem hiding this comment.
Does it really have to be a product? How long does this test take?
I'm not saying to change it, but rather to raise awareness about the potential impact of overusing Cartesian products of arguments.
There was a problem hiding this comment.
Sure, I try to keep them from exploding. For example the batch_size and the number of magnitdue bins are function of the params above not a factor in the product.
Here, the test is rather fast and simple. Its point is excaly to make sure that the pipeline builds and runs with all the combinations of the major parameters.
Signed-off-by: Kamil Tokarski <ktokarski@nvidia.com>
|
Rebased onto: #4753 |
|
!build |
|
CI MESSAGE: [7838523]: BUILD STARTED |
|
CI MESSAGE: [7838523]: BUILD FAILED |
Signed-off-by: Kamil Tokarski <ktokarski@nvidia.com>
|
!build |
|
CI MESSAGE: [7885825]: BUILD STARTED |
stiepan
added
the
automatic augmentations
|
CI MESSAGE: [7885825]: BUILD PASSED |
Category:
New feature (non-breaking change which adds functionality)
Description:
Now, that all predefined augmentations support CPU inputs, we can make the AutoAugment, RandAugment and TrivialAugment support the CPU samples. It is mostly a docs and tests update.
One extra thing is a change to the
@augmentationdecorator'sparam_devicearg. It controls the backend of the Constant node with the precomputed argument for the augmentation. Initially, it supported simply cpu or gpu. For the most part, if the parameter is used in the augmentation as a named argument to some operator, it must be cpu. However, in some cases it is used as a positional argument (or implicitly so, with arithmetic operators). Then, it makes sense to put it on gpu if samples are on gpu too. For this reason, the third option is added, the "auto" option which infers the cpu, gpu backend from the sample's DataNode.Additional information:
Affected modules and functionalities:
Key points relevant for the review:
Tests:
Checklist
Documentation
DALI team only
Requirements
REQ IDs: N/A
JIRA TASK: DALI-3296