Feature/ml model skeleton

[xiaoya27]

Type

• Bug fix (non-breaking change which fixes an issue): Fixes #
• New feature (non-breaking change which adds functionality). Resolves #
• Breaking change (fix or feature that would cause existing functionality to not work as expected) Resolves #

Motivation and Context

This is part of the #6778 initiative and part of the roadmap in the discussion . It adds the foundational open3d::ml::Model class that will allow loading PyTorch models exported via AOTInductor for C++ inference.

This PR establishes the API skeleton. Follow-up PRs will implement:

• LibtorchLoader with dlopen (PR2)
• DLPack tensor conversion to enable zero-copy data exchange between Open3D and PyTorch (PR3)
• Implementation of the forward() pass with a basic linear layer unit test (PR4)
• End-to-end integration example using a model like GeDI(PR5)

Checklist:

• I have run python util/check_style.py --apply to apply Open3D code style to my code.
• This PR changes Open3D behavior or adds new functionality.
  • Both C++ (Doxygen) and Python (Sphinx / Google style) documentation is updated accordingly.
  • I have added or updated C++ and / or Python unit tests OR included test results (e.g. screenshots or numbers) here.
• I will follow up and update the code if CI fails.
• For fork PRs, I have selected Allow edits from maintainers.

Description

Adds open3d::ml::Model class with:

• LoadModel(path) - stub for loading model artifacts
• Forward(inputs) - stub for running inference
• IsPyTorchRuntimeEnabled() - compile-time check for BUILD_PYTORCH_OPS
• OPEN3D_BUILD_PYTORCH_OPS compile definition

Unit tests included for basic API validation.

[update-docs]

Thanks for submitting this pull request! The maintainers of this repository would appreciate if you could update the CHANGELOG.md based on your changes.

[ssheorey]

Hi @xiaoya27 thanks for picking this up! This is awesome!

We already have DLPack support, so you should be able to skip this.

Also, since the roadmap discussion, PyTorch has released executorch which is specifically designed for deployment (inference). This is quite a bit lighter than full PyTorch, while being compatible with PyTorch checkpoints. We should switch to executorch for Open3D.

https://pytorch.org/blog/introducing-executorch-1-0/

[xiaoya27]

Thanks @ssheorey! ExecuTorch makes a lot of sense here given its focus on lean inference. I'd like to clarify the integration strategy:

• Integration Method: Given ExecuTorch's modular nature, would you prefer it as a CMake build option (e.g., -DBUILD_EXECUTORCH=ON) that links the runtime at compile-time, or should I stick to the dlopen approach to keep the core Open3D shared library completely independent? (I'm leaning towards CMake for better stability and simpler code).
• DLPack: Noted! I see Open3D has Tensor::ToDLPack() / Tensor::FromDLPack() already. I'll use these for tensor conversion.
• Revised PR: I will update PR Feature/ml model skeleton #7414 to reflect this shift toward ExecuTorch

[ssheorey]

Either approach - dlopen() or static / shared link at build time is fine. We will accept either. The cmake code required will likely be very similar. dlopen() has the advantage of keeping this heavy feature optional for users of the Open3D binaries / python package.