Add ExternalSource support to transparent pipelining#6401
Conversation
6bb2b6b to
62f9da2
Compare
62f9da2 to
631b805
Compare
631b805 to
a66dc6b
Compare
|
!build |
|
CI MESSAGE: [55677891]: BUILD STARTED |
a66dc6b to
acd6c9a
Compare
|
!build |
|
CI MESSAGE: [55678954]: BUILD STARTED |
|
CI MESSAGE: [55678954]: BUILD PASSED |
acd6c9a to
7ac00e9
Compare
| raise ValueError("num_outputs must be strictly positive") | ||
| self._num_outputs = num_outputs | ||
| self._device = device | ||
| self._device = _as_device(device) |
There was a problem hiding this comment.
This changes when device="gpu" is resolved. Previously we stored the string and as_tensor/as_batch resolved it when the source was called, inside the active EvalContext. Now _as_device(device) resolves it in the constructor and captures whichever GPU is current at that time.
For example, if the source is created on GPU 0 and later compiled with EvalContext(device_id=1), its data will still be created on GPU 0 while the pipeline runs on GPU 1.
Could we keep the device unresolved until execution, or resolve it when the compiled context becomes active? It would also be useful to test creating the source outside an explicit EvalContext and running it inside one.
7ac00e9 to
f0a32d9
Compare
|
!build |
|
CI MESSAGE: [56746334]: BUILD STARTED |
|
CI MESSAGE: [56746334]: BUILD FAILED |
7e8fd55 to
5b96bc2
Compare
|
!build |
|
CI MESSAGE: [57248017]: BUILD STARTED |
|
CI MESSAGE: [57248017]: BUILD FAILED |
5b96bc2 to
7266f59
Compare
Signed-off-by: Rostan Tabet <rtabet@nvidia.com>
Signed-off-by: Rostan Tabet <rtabet@nvidia.com>
Signed-off-by: Rostan Tabet <rtabet@nvidia.com>
Signed-off-by: Rostan Tabet <rtabet@nvidia.com>
7266f59 to
e6d9e97
Compare
Signed-off-by: Rostan Tabet <rtabet@nvidia.com>
e6d9e97 to
e292797
Compare
|
!build |
|
CI MESSAGE: [57391158]: BUILD STARTED |
|
CI MESSAGE: [57391158]: BUILD PASSED |
Category:
New feature (non-breaking change which adds functionality)
Description:
#6395 adds
ndd.ExternalSource. This PR makes it usable with transparent pipelining.It's usable in two ways:
.compiled(batch_size)to iterate on it.In the second case, we need to make sure that every source seen during tracing is called (exactly once) during each compiled iteration as the executor pulls data anyway, which could create misaligned states.
This PR generalizes the concept of source in
_compile.pyand decouplesCompileContextfrom readers. TheSupportsCompileprotocol is implemented by bothReaderandExternalSourceallowing both to be used as sources through duck typing.Additional information:
Affected modules and functionalities:
Transparent pipelining.
Key points relevant for the review:
This is a follow-up for #6395.
Tests:
Checklist
Documentation
DALI team only
Requirements
REQ IDs: N/A
JIRA TASK: DALI-4745