💊 CI failures summary and remediations

As of commit 09a3f41 (more details on the Dr. CI page and at hud.pytorch.org/pr/61882):

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

Preview docs built from this PR

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

Do you know by how much it slows things down?

I haven't run the performance. It's no worse than calling the fully dispatched at::empty factory function, though, since that already calls it in the wrapper (as in, structured kernels had some ill gotten gains that we're being more realistic about.)

However, your comment got me thinking about whether or not initializing CUDA in structured functions really is necessary. After all, if you are given a CUDA tensor, the invariant ought to be that CUDA is already initialized. Indeed #61642 only tickles the problem through a very particular case:

TEST(CUDACaffe2ToPytorch, Op) {
  if (!at::cuda::is_available()) return;
  caffe2::Tensor c2_tensor =
      caffe2::empty({3, 3}, at::dtype<int64_t>().device(caffe2::CUDA));
  auto data = c2_tensor.mutable_data<int64_t>();
  {
    caffe2::CUDAContext context;
    caffe2::math::Set<int64_t>(9, 111, data, &context);
  }
  at::Tensor at_tensor(c2_tensor);
  ASSERT_TRUE(at_tensor.is_cuda());

  ASSERT_EQ(at::sum(at_tensor).item<int64_t>(), 999);
}

what I bet is happening is that at::Tensor at_tensor(c2_tensor); is how this test bypasses lazy initialization entirely. So maybe if we just add it there that will suffice...

Drat! I can't easily force the initialization in the constructor because it's in ATen/core and the context is in ATen

Is it worth checking the slowdown before landing, or do we not really have a choice if we want to fix it?

I think the correct terminal state is to not initialize here, and fix the caffe2-to-aten constructor. I'm going to go ahead and land this for now to unblock the other PRs though.

@ezyang merged this pull request in f3f7e92.