Use `torch::stable::Device` by NicolasHug · Pull Request #1231 · meta-pytorch/torchcodec

NicolasHug · 2026-02-11T09:59:34Z

TSIA. Good luck.

pytorch-bot · 2026-02-11T09:59:39Z

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/meta-pytorch/torchcodec/1231

📄 Preview Python docs built from this PR

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

✅ No Failures

As of commit 81a3bc5 with merge base dcac4d0 ():
💚 Looks good so far! There are no failures yet. 💚

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

NicolasHug · 2026-02-11T16:17:19Z

src/torchcodec/_core/CUDACommon.cpp

+      torch::TensorOptions()
+          .dtype(torch::kUInt8)
+          .device(torch::Device(
+              static_cast<c10::DeviceType>(device.type()), device.index())));


We're casting our stableDevice into a non-stable torch::Device, because this is what torch::zeros expects. These kinds of quirks will go away once we migrate fully to the stable ABI: we won't be relying on torch::zeros anymore, we'll be relying on its stable counterpart, which will accept a stableDevice.

I'm not making this a TODO, because this will be a forced changed.

NicolasHug · 2026-02-11T16:20:23Z

test/third-party-interface/ThirdPartyInterfaceTest.cpp

 class DummyDeviceInterface : public DeviceInterface {
 public:
-  DummyDeviceInterface(const torch::Device& device) : DeviceInterface(device) {}
+  DummyDeviceInterface(const StableDevice& device) : DeviceInterface(device) {}


FYI @dvrogozh , I think we'll move forward with this, which means third-party interfaces will need to use StableDevice. This is a subset of the changes from #1188, as I'll try to do the port in stages.

Ok, I see that's now not a draft, so I assume it's ready for review and try out?

NicolasHug · 2026-02-11T16:48:49Z

src/torchcodec/_core/CMakeLists.txt

+            "-Wno-attributes"
+        )
+    endif()
+


NicolasHug · 2026-02-11T16:58:08Z

src/torchcodec/_core/DeviceInterface.h

+    std::function<DeviceInterface*(const StableDevice& device)>;

-bool registerDeviceInterface(
+TORCHCODEC_THIRD_PARTY_API bool registerDeviceInterface(


The TORCHCODEC_THIRD_PARTY_API helper ensures the registerDeviceInterface symbol is properly public - which is needed because it is called by third-party libraries. Note that it was already public on main! Now with this PR, we need to force it to public, because it would otherwise get demoted to hidden. Why? Because some of its parameters CreateDeviceInterfaceFn transitively depends on a hidden type, namely StableDevice. Because StableDevice is hidden, the compiler will by default demote everything that also depends on it - that includes registerDeviceInterface. Hence why we have to force this back to public.

Also relevant: https://github.com/meta-pytorch/torchcodec/pull/1231/changes#r2794367843

Dan-Flores · 2026-02-11T18:45:09Z

src/torchcodec/_core/CudaDeviceInterface.cpp

  // Create hardware device context
-  c10::cuda::CUDAGuard deviceGuard(device);
+  c10::cuda::CUDAGuard deviceGuard(
+      c10::Device(static_cast<c10::DeviceType>(device.type()), device.index()));


Is this a similar case to torch::zeros, where we must cast to a non-stable torch::Device until a stable counterpart for CUDAGuard is implemented?

Dan-Flores · 2026-02-11T18:45:33Z

src/torchcodec/_core/CudaDeviceInterface.cpp

    } else {
-      frameOutput.data = cpuFrameOutput.data.to(device_);
+      frameOutput.data = cpuFrameOutput.data.to(torch::Device(
+          static_cast<c10::DeviceType>(device_.type()), device_.index()));


I saw there is a torch::stable::Tensor defined. I assume we are saving that migration for a separate PR?

Yes this is probably going to be the next (and biggest) migration

Dan-Flores · 2026-02-11T19:15:29Z

src/torchcodec/_core/StableABICompat.h

+using StableDeviceIndex = torch::stable::accelerator::DeviceIndex;
+
+// DeviceGuard for CUDA context management
+using StableDeviceGuard = torch::stable::accelerator::DeviceGuard;


We aren't using this currently. Was this meant to be used in CudaDeviceInterface.cpp instead of casting back to torch::Device in deviceGuard?

Good catch, thanks. I'll remove it for now and do a separate migration for all the "CUDA stuff" (streams sync, guards, etc.)

mollyxu · 2026-02-11T19:54:13Z

src/torchcodec/_core/CudaDeviceInterface.cpp

      "Expected 3D RGB tensor (CHW format), got shape: ",
      tensor.sizes());
  STD_TORCH_CHECK(
      tensor.device().type() == torch::kCUDA,


To double check my understanding, once we switch to torch::stable::Tensor, we would modify this comparison to kStableCuda?

mollyxu · 2026-02-11T20:36:13Z

src/torchcodec/_core/DeviceInterface.cpp

 // LICENSE file in the root directory of this source tree.

 #include "DeviceInterface.h"
+#include <cstring>


I couldn't find specific instances where we were using functions from this header but I might've missed something. Maybe this is something that is related to the rest of porting to stable ABI?

Good catch thank you

…_device

Dan-Flores

Thanks for working on this! I left one clarifying question, but the changes LGTM!

Dan-Flores · 2026-02-12T14:19:56Z

src/torchcodec/_core/CMakeLists.txt

+    # - the StableDevice field has "hidden" visibility because this is how
+    #   torch::stable exports it.
+    # This creates this mismatch where a class has "higher" visibility than its
+    # member, hence the warning.


Is the issue that the compiler is trying to prevent here that: A user of VideoStreamOptions could try to call a method of StableDevice, but since StableDevice is "hidden", that method will not be available (due to the linker not finding it when building?)

And the reason we can ignore this warning is: StableDevice is header only, so all the functions are inline and will be available in each built .so file, so no linker issues will occur.

Is this your understanding? I read this wiki to try to understand the visibility attribute, but it is a little hard to apply to our situation.

What's going on is along the same vein as what you're describing, but it's not quite exactly that.

With the warning, the compiler is essentially telling us "Hey, that VideoStreamOptions class is supposed to have public visibility, but one of its field has hidden visibility. I'm going to have to make the class hidden too!!".

We can get away with this warning, because we're fine with VideoStreamOptions being hidden since no other (dynamically loaded) library is relying on VideoStreamOptions.

The key primer here, is that:

a public symbol can be dynamically loaded by another library

a private symbol cannot

(see also https://claude.ai/share/0f9ce2e8-0a98-47d1-a4dc-286e618a89e2)

Here, we don't have any library that dynamically loads the core library and that relies on VideoStreamOptions, so it can be private.

Use torch::stable::Device

67fd0e5

meta-cla bot added the CLA Signed This label is managed by the Meta Open Source bot. label Feb 11, 2026

NicolasHug added 5 commits February 11, 2026 11:17

Fix some stuff

36480ff

remove -fvisibility=default for core lib

52c349c

Put no-attribute as global flag

0c16eaa

Protect for linux only

be70e81

fix test

6f1cf88

NicolasHug commented Feb 11, 2026

View reviewed changes

Comments

2c0d678

NicolasHug commented Feb 11, 2026

View reviewed changes

NicolasHug marked this pull request as ready for review February 11, 2026 17:04

Dan-Flores reviewed Feb 11, 2026

View reviewed changes

mollyxu reviewed Feb 11, 2026

View reviewed changes

NicolasHug added 2 commits February 12, 2026 09:08

Remove unused stuff

4cc6346

Merge branch 'main' of github.com:meta-pytorch/torchcodec into stable…

81a3bc5

…_device

Dan-Flores approved these changes Feb 12, 2026

View reviewed changes

NicolasHug merged commit 6f10da0 into meta-pytorch:main Feb 12, 2026
68 checks passed

NicolasHug deleted the stable_device branch February 12, 2026 14:37

Conversation

NicolasHug commented Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pytorch-bot bot commented Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/meta-pytorch/torchcodec/1231

✅ No Failures

Uh oh!

NicolasHug Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NicolasHug Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Dan-Flores left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

NicolasHug commented Feb 11, 2026 •

edited

Loading

pytorch-bot bot commented Feb 11, 2026 •

edited

Loading

NicolasHug Feb 11, 2026 •

edited

Loading

NicolasHug Feb 11, 2026 •

edited

Loading