🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/119639

• 📄 Preview Python docs built from this PR
• 📄 Preview C++ docs built from this PR
• ❓ Need help or want to give feedback on the CI? Visit the bot commands wiki or our office hours

Note: Links to docs will display an error until the docs builds have been completed.

❌ 19 New Failures

As of commit 0bdcec4 with merge base bcb4f7c ():

This comment was automatically generated by Dr. CI and updates every 15 minutes.

@tringwald We need to search and replace all occurrences of std::numerical_limits<c10::DeviceIndex>::max() with C10_COMPILE_TIME_MAX_GPUS

Maybe we should just replace all C10_COMPILE_TIME_MAX_GPUS with the new C10_MAX_NUM_DEVICES if we want to keep the device count consistent for all device types.

Maybe we should just replace all C10_COMPILE_TIME_MAX_GPUS with the new C10_MAX_NUM_DEVICES if we want to keep the device count consistent for all device types.

It's better to use a single macro, and it is even better to change it into a constexpr variable to avoid possible upgrading issues in the future.

Maybe we should just replace all C10_COMPILE_TIME_MAX_GPUS with the new C10_MAX_NUM_DEVICES if we want to keep the device count consistent for all device types.

It's better to use a single macro, and it is even better to change it into a constexpr variable to avoid possible upgrading issues in the future.

Something like this maybe?

// c10/core/Device.h
namespace c10 {
    constexpr DeviceIndex MAX_NUM_DEVICES = 512;

    struct C10_API Device final {
        // ...
    }
}

or

// c10/core/Device.h
namespace c10 {
    struct C10_API Device final {
        static constexpr DeviceIndex MAX_NUM_DEVICES = 512;
    }
}

IMO, the first case is better

@pytorchbot rebase

@pytorchbot label ciflow/binaries

@pytorchbot started a rebase job onto refs/remotes/origin/viable/strict. Check the current status here

Successfully rebased increase-max-gpu-count onto refs/remotes/origin/viable/strict, please pull locally before adding more changes (for example, via git checkout increase-max-gpu-count && git pull --rebase)

Hey @tringwald @cyyever @albanD @kit1980 @huydhn

Is there a plan for when this change can be merged? The 120 GPU limit is restrictive. cc: @jeffdaily @jithunnair-amd

I see the dependent PR is mostly approved #122527 but I assume there is still internal testing ongoing for this? And do we actually need the full removal of Caffe2 to move with the int16_t change?

@albanD has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

A few of the APIs being removed are used, so this needs manual fixing before it can land.

Are you referring to Meta-internal code? I think @kit1980 has done some work on the Meta side.

I think @kit1980 has done some work on the Meta side.

I could not figure out one item and then caffe2 desync caused additional issues.

Looks like this PR hasn't been updated in a while so we're going to go ahead and mark this as Stale.
Feel free to remove the Stale label if you feel this was a mistake.
If you are unable to remove the Stale label please contact a maintainer in order to do so.
If you want the bot to never mark this PR stale again, add the no-stale label.
Stale pull requests will automatically be closed after 30 days of inactivity.