Don't store device indices separately on FutureNCCL

[lw]

Stack from ghstack:

• Add support for async callbacks in ivalue::Future #48790 Add support for async callbacks in ivalue::Future
• Drop FutureNCCL in favor of vanilla CUDAFuture #49014 Drop FutureNCCL in favor of vanilla CUDAFuture
• Make CUDAFuture remember and restore current device in callback #48789 Make CUDAFuture remember and restore current device in callback
• Remove DataPtr extractor from CUDAFuture #48840 Remove DataPtr extractor from CUDAFuture
• Cache the DataPtrs in CUDAFuture #48788 Cache the DataPtrs in CUDAFuture
• Split out reusable CUDAFuture from FutureNCCL #48506 Split out reusable CUDAFuture from FutureNCCL
• Merge common parts of FutureNCCL into at::ivalue::Future #48505 Merge common parts of FutureNCCL into at::ivalue::Future
• Split FutureNCCL's CUDA-specific parts from generic future logic #48504 Split FutureNCCL's CUDA-specific parts from generic future logic
• Support wider range of types in FutureNCCL #48502 Support wider range of types in FutureNCCL
• Don't store device indices separately on FutureNCCL #48501 Don't store device indices separately on FutureNCCL
• Add multi-GPU support to FutureNCCL #48500 Add multi-GPU support to FutureNCCL
• Fix FutureNCCL not recording dataptrs with caching alloc in wait() #48563 Fix FutureNCCL not recording dataptrs with caching alloc in wait()
• Fix FutureNCCL's completed() disagreeing with wait() #48503 Fix FutureNCCL's completed() disagreeing with wait()
• Record CUDA events for "follow-up" FutureNCCL inside markCompleted #48499 Record CUDA events for "follow-up" FutureNCCL inside markCompleted
• Use fresh stream from pool for each FutureNCCL callback #48498 Use fresh stream from pool for each FutureNCCL callback
• Make FutureNCCL record events in current stream #48497 Make FutureNCCL record events in current stream
• Have FutureNCCL record streams w/ allocator in addCallback #48496 Have FutureNCCL record streams w/ allocator in addCallback
• Add some safeguards to FutureNCCL #48562 Add some safeguards to FutureNCCL
• Remove NCCL dependency from PythonFutureWrapper #48495 Remove NCCL dependency from PythonFutureWrapper
• Avoid using FutureNCCL before it's ready #48561 Avoid using FutureNCCL before it's ready

This commit is part of a stack that reworks FutureNCCL in order to extract a generic CUDA-aware Future subclass. The stack deliberately breaks up this transition into elementary changes, to make it easier to verify that the behavior is preserved (or to highlight how it gets changed).

---

FutureNCCL stores a set of devices (on which the tensors in the data reside) and a CUDA event for each of those devices. In fact, each event instance also already contains the device it belongs to, which means we can avoid storing that information separately (with the risk that it'll be mismatched and/or inaccurate).

Differential Revision: D25177554

[mrshenli]

LGTM!

(with the risk that it'll be mismatched and/or inaccurate).

When will this happen? Would I be correct if I assume users won't trigger this as FutureNCCL is an internal type?

[dr-ci]

💊 CI failures summary and remediations

As of commit a490ec1 (more details on the Dr. CI page):

---

💚 💚 Looks good so far! There are no failures yet. 💚 💚

---

This comment was automatically generated by Dr. CI (expand for details).

Follow this link to opt-out of these comments for your Pull Requests.

Please report bugs/suggestions on the GitHub issue tracker or post in the (internal) Dr. CI Users group.

See how this bot performed.

This comment has been revised 28 times.

[lw]

When will this happen?

Yes, I meant this mostly as a risk of programming error.

[facebook-github-bot]

This pull request has been merged in 9fe3ac3.