🔗 Helpful Links

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

• 📄 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.

❌ 3 New Failures

As of commit e3237f0 with merge base 12b0213 ():

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

The committers listed above are authorized under a signed CLA.

• ✅ login: trajepl / name: trajep (b09a4bf, 7f38a3f, 4dc8142, ffc723c, e3237f0, ebedd53)

@pytorchbot label "topic: not user facing"

@albanD Would it be reasonable to move is_pinned to HostAllocator at this point, similar to what was done in #151439?

I'm a bit concerned by the direction here actually.
If the intent is to make this a full fledged device and not what ORT was before, then I expect we are embarking here into a multi-month project to add all the scaffolding into the core lib.
We should discuss in more details before starting on that path, especially given that we now have fully working out-of-tree extension point where all this scaffolding is done and are ready for use today (see e2e example in https://github.com/pytorch/pytorch/tree/main/test/cpp_extensions/open_registration_extension )

Let's sync on an issue or slack about this before you start working on more of these PRs.

I'm a bit concerned by the direction here actually.
If the intent is to make this a full fledged device and not what ORT was before, then I expect we are embarking here into a multi-month project to add all the scaffolding into the core lib. We should discuss in more details before starting on that path, especially given that we now have fully working out-of-tree extension point where all this scaffolding is done and are ready for use today (see e2e example in https://github.com/pytorch/pytorch/tree/main/test/cpp_extensions/open_registration_extension )

Let's sync on an issue or slack about this before you start working on more of these PRs.

Thanks for raising this @albanD — I understand your concern and agree that long-term, using the open registration (PrivateUse1) mechanism is the right direction for out-of-tree backend integration.

That said, our current backend has already been deeply integrated using the older in-tree approach. We have implemented a wide range of kernels and system components (memory, distributed, collective, dispatch, etc.) based on this, and the transition to PrivateUse1 is non-trivial for us in the short term.

We’re not opposed to making this shift, but given the amount of scaffolding already built, we would need to plan and migrate incrementally. We're happy to align with the openReg approach long-term and would appreciate guidance or best practices to gradually restructure our integration around PrivateUse1.

Let’s sync up in this issue to discuss a possible migration path that minimizes disruption to our current functionality while moving toward the recommended direction.

cc @wschin

@albanD, as you saw above, we built our code on previous integration approach, so switching to OpenReg will take months to make this simple change happen. From PRs to OpenReg, it seems it's still under development without clear documents. We are investigating for a feasible migration plan to OpenReg. To unblock our production code and lower our risk, could you please re-consider if this PR can be accepted?

Some concerns for OpenReg: #155864 (comment)

Move to use private_use1. Close this PR. More details can be found in #155864