enables default data step in megatron parallel to operate on a wider variety of tensors

[jomitchellnv]

…variety of tensors coming out of the dataloader

Add more flexibility to the default data step inside megatron parallel.

Add a one line overview of what this PR aims to accomplish.

Collection: [Note which collection this PR will affect]

Changelog

• Megatron parallel's default data step can operate on wrapped tuples and unwrapped items coming directly out of the dataloader

Usage

• You can potentially add a usage example below

# Add a code snippet demonstrating how to use this 

GitHub Actions CI

The Jenkins CI system has been replaced by GitHub Actions self-hosted runners.

The GitHub Actions CI will run automatically when the "Run CICD" label is added to the PR.
To re-run CI remove and add the label again.
To run CI on an untrusted fork, a NeMo user with write access must first click "Approve and run".

Before your PR is "Ready for review"

Pre checks:

• Make sure you read and followed Contributor guidelines
• Did you write any new necessary tests?
• Did you add or update any necessary documentation?
• Does the PR affect components that are optional to install? (Ex: Numba, Pynini, Apex etc)
  • Reviewer: Does the PR have correct import guards for all optional libraries?

PR Type:

• New Feature
• Bugfix
• Documentation

If you haven't finished some of the above items you can still open "Draft" PR.

Who can review?

Anyone in the community is free to review the PR once the checks have passed.
Contributor guidelines contains specific people who can review PRs to various areas.

Additional Information

• Related to # (issue)

[jstjohn]

This comment is not what happens anymore. Now in your else you say raise ValueError(...):. Are we sure we don't want to pass through a None on the iter? Otherwise we should prob change line 79 or 84 to return None and drop the ValueError piece.

[jstjohn]

Actually what I hope would happen is that the match(dataloader_iter) would trigger an StopIteration or whatever it is exception rather than returning None. The StopIteration exception ideally would raise through this function (what happens now on the match) and be handled elsewhere. So I think your case _ should never get hit...

[jstjohn]

Maybe a better error message on line 84 would be "None batch returned at the end of iteration rather than a StopIteration exception being raised, why?"

[jomitchellnv]

So I only added this to be past the linter. I updated the comment so that its more accurate. My only concern would be how it plays out with drop_last=True since maybe that would dump some None's?