Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[pybind] New Runtime pybind API #6063

Closed
wants to merge 1 commit into from
Closed

[pybind] New Runtime pybind API #6063

wants to merge 1 commit into from

Conversation

larryliu0820
Copy link
Contributor

@larryliu0820 larryliu0820 commented Oct 9, 2024 •
edited
Loading

Summary:
Based on this proposal: https://docs.google.com/document/d/10Q4-pt97inQQtFf-FjjwhMaDXXCfk1zGy6V6EkygNUY/edit#heading=h.fcrpnrtb6cud

Historically our pybinding APIs are not following the same C++ modeling
(Program, Method etc) and hence it's hard to use and easy to hit
footguns - for example, if we load the program and return it from a
python method, it goes out of the scope and releases the memory.

This effort is to create Pybind APIs that resembles C++ objects so it's
less confusing to the users.

Add the following python classes:

  • Runtime: a singleton object hosting methods like load_program.
    Returns a Program object when calling load_program. Also exposes
    the operator registry
  • Program: each pte file should have one Program object. Most
    important method is load_method which returns a Method object. It
    has a property method_names where we can inspect what methods are
    inside this .pte file.
  • Method: one object per method name in a given Program. Exposes
    execute which takes in pytree flattened torch tensors as input and
    return pytree flattened output. It also exposes MethodMeta for users
    to inspect more information regarding input/output of this method.

Test Plan:

Reviewers:

Subscribers:

Tasks:

Tags:

@pytorch-bot PyTorch Bot
Copy link

pytorch-bot bot commented Oct 9, 2024 •
edited
Loading

🔗 Helpful Links

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

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

✅ No Failures

As of commit 2a34c34 with merge base df5b2ab (image):
💚 Looks good so far! There are no failures yet. 💚

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

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Oct 9, 2024
@facebook-github-bot
Copy link
Contributor

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

dbort
dbort requested changes Oct 9, 2024
View reviewed changes
Copy link
Contributor

@dbort dbort left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great! Mostly small issues.

runtime/__init__.py Outdated Show resolved Hide resolved
runtime/__init__.py Show resolved Hide resolved
runtime/__init__.py Outdated Show resolved Hide resolved
runtime/__init__.py Outdated Show resolved Hide resolved
runtime/__init__.py Outdated Show resolved Hide resolved
runtime/test/test_runtime.py Outdated Show resolved Hide resolved
runtime/test/test_runtime.py Outdated Show resolved Hide resolved
runtime/__init__.py Outdated Show resolved Hide resolved
runtime/__init__.py Outdated Show resolved Hide resolved
runtime/__init__.py Outdated Show resolved Hide resolved
@facebook-github-bot
Copy link
Contributor

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

dbort
dbort approved these changes Oct 10, 2024
View reviewed changes
Copy link
Contributor

@dbort dbort left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few final minor things, but looks great!

runtime/__init__.py Outdated Show resolved Hide resolved
runtime/__init__.py Outdated Show resolved Hide resolved
runtime/__init__.py Outdated Show resolved Hide resolved
runtime/__init__.py Outdated Show resolved Hide resolved
runtime/__init__.py Outdated Show resolved Hide resolved
runtime/__init__.py Outdated Show resolved Hide resolved
runtime/__init__.py Outdated Show resolved Hide resolved
runtime/__init__.py Outdated Show resolved Hide resolved
@facebook-github-bot
Copy link
Contributor

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

facebook-github-bot pushed a commit that referenced this pull request Oct 10, 2024
@larryliu0820 @facebook-github-bot
New Runtime pybind API (#6063)
bcb1e0e 
Summary:
Based on this proposal: https://docs.google.com/document/d/10Q4-pt97inQQtFf-FjjwhMaDXXCfk1zGy6V6EkygNUY/edit#heading=h.fcrpnrtb6cud
    
Historically our pybinding APIs are not following the same C++ modeling
(Program, Method etc) and hence it's hard to use and easy to hit
footguns - for example, if we load the program and return it from a
python method, it goes out of the scope and releases the memory.

This effort is to create Pybind APIs that resembles C++ objects so it's
less confusing to the users.

Add the following python classes:
* `Runtime`: a singleton object hosting methods like `load_program`.
  Returns a `Program` object when calling `load_program`. Also exposes
  the operator registry
* `Program`: each pte file should have one `Program` object. Most
  important method is `load_method` which returns a `Method` object. It
  has a property `method_names` where we can inspect what methods are
  inside this .pte file.
* `Method`: one object per method name in a given `Program`. Exposes
  `execute` which takes in pytree flattened torch tensors as input and
  return pytree flattened output. It also exposes `MethodMeta` for users
  to inspect more information regarding input/output of this method.


Reviewed By: dbort

Differential Revision: D64132360

Pulled By: larryliu0820
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D64132360

facebook-github-bot pushed a commit that referenced this pull request Oct 10, 2024
@larryliu0820 @facebook-github-bot
New Runtime pybind API (#6063)
3e854de 
Summary:
Based on this proposal: https://docs.google.com/document/d/10Q4-pt97inQQtFf-FjjwhMaDXXCfk1zGy6V6EkygNUY/edit#heading=h.fcrpnrtb6cud
    
Historically our pybinding APIs are not following the same C++ modeling
(Program, Method etc) and hence it's hard to use and easy to hit
footguns - for example, if we load the program and return it from a
python method, it goes out of the scope and releases the memory.

This effort is to create Pybind APIs that resembles C++ objects so it's
less confusing to the users.

Add the following python classes:
* `Runtime`: a singleton object hosting methods like `load_program`.
  Returns a `Program` object when calling `load_program`. Also exposes
  the operator registry
* `Program`: each pte file should have one `Program` object. Most
  important method is `load_method` which returns a `Method` object. It
  has a property `method_names` where we can inspect what methods are
  inside this .pte file.
* `Method`: one object per method name in a given `Program`. Exposes
  `execute` which takes in pytree flattened torch tensors as input and
  return pytree flattened output. It also exposes `MethodMeta` for users
  to inspect more information regarding input/output of this method.


Reviewed By: dbort

Differential Revision: D64132360

Pulled By: larryliu0820
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D64132360

facebook-github-bot pushed a commit that referenced this pull request Oct 10, 2024
@larryliu0820 @facebook-github-bot
New Runtime pybind API (#6063)
24ee85a 
Summary:
Based on this proposal: https://docs.google.com/document/d/10Q4-pt97inQQtFf-FjjwhMaDXXCfk1zGy6V6EkygNUY/edit#heading=h.fcrpnrtb6cud
    
Historically our pybinding APIs are not following the same C++ modeling
(Program, Method etc) and hence it's hard to use and easy to hit
footguns - for example, if we load the program and return it from a
python method, it goes out of the scope and releases the memory.

This effort is to create Pybind APIs that resembles C++ objects so it's
less confusing to the users.

Add the following python classes:
* `Runtime`: a singleton object hosting methods like `load_program`.
  Returns a `Program` object when calling `load_program`. Also exposes
  the operator registry
* `Program`: each pte file should have one `Program` object. Most
  important method is `load_method` which returns a `Method` object. It
  has a property `method_names` where we can inspect what methods are
  inside this .pte file.
* `Method`: one object per method name in a given `Program`. Exposes
  `execute` which takes in pytree flattened torch tensors as input and
  return pytree flattened output. It also exposes `MethodMeta` for users
  to inspect more information regarding input/output of this method.


Reviewed By: dbort

Differential Revision: D64132360

Pulled By: larryliu0820
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D64132360

@larryliu0820 @facebook-github-bot
New Runtime pybind API (#6063)
2a34c34 
Summary:
Based on this proposal: https://docs.google.com/document/d/10Q4-pt97inQQtFf-FjjwhMaDXXCfk1zGy6V6EkygNUY/edit#heading=h.fcrpnrtb6cud
    
Historically our pybinding APIs are not following the same C++ modeling
(Program, Method etc) and hence it's hard to use and easy to hit
footguns - for example, if we load the program and return it from a
python method, it goes out of the scope and releases the memory.

This effort is to create Pybind APIs that resembles C++ objects so it's
less confusing to the users.

Add the following python classes:
* `Runtime`: a singleton object hosting methods like `load_program`.
  Returns a `Program` object when calling `load_program`. Also exposes
  the operator registry
* `Program`: each pte file should have one `Program` object. Most
  important method is `load_method` which returns a `Method` object. It
  has a property `method_names` where we can inspect what methods are
  inside this .pte file.
* `Method`: one object per method name in a given `Program`. Exposes
  `execute` which takes in pytree flattened torch tensors as input and
  return pytree flattened output. It also exposes `MethodMeta` for users
  to inspect more information regarding input/output of this method.


Reviewed By: dbort

Differential Revision: D64132360

Pulled By: larryliu0820
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D64132360

@facebook-github-bot
Copy link
Contributor

@larryliu0820 merged this pull request in ba8dc28.

larryliu0820 added a commit that referenced this pull request Oct 11, 2024
@larryliu0820
New Runtime pybind API (#6063)
d2628be 
Summary:
Based on this proposal: https://docs.google.com/document/d/10Q4-pt97inQQtFf-FjjwhMaDXXCfk1zGy6V6EkygNUY/edit#heading=h.fcrpnrtb6cud

Historically our pybinding APIs are not following the same C++ modeling
(Program, Method etc) and hence it's hard to use and easy to hit
footguns - for example, if we load the program and return it from a
python method, it goes out of the scope and releases the memory.

This effort is to create Pybind APIs that resembles C++ objects so it's
less confusing to the users.

Add the following python classes:
* `Runtime`: a singleton object hosting methods like `load_program`.
  Returns a `Program` object when calling `load_program`. Also exposes
  the operator registry
* `Program`: each pte file should have one `Program` object. Most
  important method is `load_method` which returns a `Method` object. It
  has a property `method_names` where we can inspect what methods are
  inside this .pte file.
* `Method`: one object per method name in a given `Program`. Exposes
  `execute` which takes in pytree flattened torch tensors as input and
  return pytree flattened output. It also exposes `MethodMeta` for users
  to inspect more information regarding input/output of this method.

Pull Request resolved: #6063

Reviewed By: dbort

Differential Revision: D64132360

Pulled By: larryliu0820

fbshipit-source-id: a2f35edc5fd8c200df0812a693e454d66d6a907e
@larryliu0820 larryliu0820 mentioned this pull request Oct 11, 2024
Merged
larryliu0820 added a commit that referenced this pull request Oct 11, 2024
@larryliu0820
New Runtime pybind API (#6063)
24c9d66 
Summary:
Based on this proposal: https://docs.google.com/document/d/10Q4-pt97inQQtFf-FjjwhMaDXXCfk1zGy6V6EkygNUY/edit#heading=h.fcrpnrtb6cud

Historically our pybinding APIs are not following the same C++ modeling
(Program, Method etc) and hence it's hard to use and easy to hit
footguns - for example, if we load the program and return it from a
python method, it goes out of the scope and releases the memory.

This effort is to create Pybind APIs that resembles C++ objects so it's
less confusing to the users.

Add the following python classes:
* `Runtime`: a singleton object hosting methods like `load_program`.
  Returns a `Program` object when calling `load_program`. Also exposes
  the operator registry
* `Program`: each pte file should have one `Program` object. Most
  important method is `load_method` which returns a `Method` object. It
  has a property `method_names` where we can inspect what methods are
  inside this .pte file.
* `Method`: one object per method name in a given `Program`. Exposes
  `execute` which takes in pytree flattened torch tensors as input and
  return pytree flattened output. It also exposes `MethodMeta` for users
  to inspect more information regarding input/output of this method.

Pull Request resolved: #6063

Reviewed By: dbort

Differential Revision: D64132360

Pulled By: larryliu0820

fbshipit-source-id: a2f35edc5fd8c200df0812a693e454d66d6a907e
larryliu0820 added a commit that referenced this pull request Oct 11, 2024
@larryliu0820
New Runtime pybind API (#6063)
ca0e55d 
Summary:
Based on this proposal: https://docs.google.com/document/d/10Q4-pt97inQQtFf-FjjwhMaDXXCfk1zGy6V6EkygNUY/edit#heading=h.fcrpnrtb6cud

Historically our pybinding APIs are not following the same C++ modeling
(Program, Method etc) and hence it's hard to use and easy to hit
footguns - for example, if we load the program and return it from a
python method, it goes out of the scope and releases the memory.

This effort is to create Pybind APIs that resembles C++ objects so it's
less confusing to the users.

Add the following python classes:
* `Runtime`: a singleton object hosting methods like `load_program`.
  Returns a `Program` object when calling `load_program`. Also exposes
  the operator registry
* `Program`: each pte file should have one `Program` object. Most
  important method is `load_method` which returns a `Method` object. It
  has a property `method_names` where we can inspect what methods are
  inside this .pte file.
* `Method`: one object per method name in a given `Program`. Exposes
  `execute` which takes in pytree flattened torch tensors as input and
  return pytree flattened output. It also exposes `MethodMeta` for users
  to inspect more information regarding input/output of this method.

Pull Request resolved: #6063

Reviewed By: dbort

Differential Revision: D64132360

Pulled By: larryliu0820

fbshipit-source-id: a2f35edc5fd8c200df0812a693e454d66d6a907e
larryliu0820 added a commit that referenced this pull request Oct 11, 2024
@larryliu0820
New Runtime pybind API (#6063)
f5b2913 
Summary:
Based on this proposal: https://docs.google.com/document/d/10Q4-pt97inQQtFf-FjjwhMaDXXCfk1zGy6V6EkygNUY/edit#heading=h.fcrpnrtb6cud

Historically our pybinding APIs are not following the same C++ modeling
(Program, Method etc) and hence it's hard to use and easy to hit
footguns - for example, if we load the program and return it from a
python method, it goes out of the scope and releases the memory.

This effort is to create Pybind APIs that resembles C++ objects so it's
less confusing to the users.

Add the following python classes:
* `Runtime`: a singleton object hosting methods like `load_program`.
  Returns a `Program` object when calling `load_program`. Also exposes
  the operator registry
* `Program`: each pte file should have one `Program` object. Most
  important method is `load_method` which returns a `Method` object. It
  has a property `method_names` where we can inspect what methods are
  inside this .pte file.
* `Method`: one object per method name in a given `Program`. Exposes
  `execute` which takes in pytree flattened torch tensors as input and
  return pytree flattened output. It also exposes `MethodMeta` for users
  to inspect more information regarding input/output of this method.

Pull Request resolved: #6063

Reviewed By: dbort

Differential Revision: D64132360

Pulled By: larryliu0820

fbshipit-source-id: a2f35edc5fd8c200df0812a693e454d66d6a907e
larryliu0820 added a commit that referenced this pull request Oct 11, 2024
@larryliu0820 @dulinriley
Pick pybind (#6151)
040015c 
* Add MethodMeta object for python visibility (#5571)

Summary:
Pull Request resolved: #5571

Some clients and consumers of the Executorch program files (.pte) were
requesting ways to access metadata like the sizes of tensors and the number
of bytes they needed.
When I told them how to access them in C++, they requested Python wrappers
since they had processing scripts written in Python.

Add some implementations of MethodMeta and TensorInfo methods.
Note that these become more expensive than in C++ because they need to
allocate python objects, but I doubt these are used in
performance-sensitive applications anyway. And dealing with
lifetimes of mixed C++/Python objects is complex, so I favored simple lifetimes.

Reviewed By: dbort

Differential Revision: D63288433

fbshipit-source-id: af775120a8ebd9bf455671a8ce1f158259aa50e6

* Add mapping from C++ program::verification to Python (#5915)

Summary:
As titled. This enables
`portable_lib._load_for_executorch[_from_buffer]` to accept `Program::Verification` argument.

See added test, now we can do something like:

```
from executorch.extension.pybindings.portable_lib import Verification
module = load_fn(
  exported_program.buffer,
  enable_etdump=False,
  debug_buffer_size=0,
  program_verification=Verification.Minimal,
)
```

Pull Request resolved: #5915

Test Plan: See unit test

Reviewed By: dbort

Differential Revision: D63987538

Pulled By: larryliu0820

fbshipit-source-id: b68d8d1149e2d46b90544679707f420179e72b19

* Find portable_lib.so in pip package during cmake build (#5961)

Summary:
* Rename `_portable_lib.cpython-3.<distribution info>.so` to `_portable_lib.so` so it can be found by CMake `find_library()`. This can be achieved by setting `SETUPTOOLS_EXT_SUFFIX`.
* Since `executorch-config.cmake` is also being used to find installed libraries such as `executorch.a`, `xnnpack_backend.a`, add a condition to tell if `executorch-config.cmake` is being used in cmake-out or site-packages.

Pull Request resolved: #5961

Reviewed By: metascroy

Differential Revision: D64014291

Pulled By: larryliu0820

fbshipit-source-id: 2757f2883d3f836e9efd45676f792c12f742e63d

* Improve pip package build (#5965)

Summary:
Addressing comments in #5961.

* Separate out `executorch-wheel-config.cmake` from `executorch-config.cmake`.
* Hardcode the envrionment variable `SETUPTOOLS_EXT_SUFFIX` in `setup.py`.

Pull Request resolved: #5965

Reviewed By: dbort

Differential Revision: D64017947

Pulled By: larryliu0820

fbshipit-source-id: 0bdff5e2d2ec5873540d1b701595c7a316e84e80

* Let find_package(executorch) find the correct include directory (#6102)

Summary:
There's a typo in `executorch-wheel-config.cmake` that points to the wrong `include` path:
```
<site-packages>/executorch/share/cmake/include
```

Where it actually should be
```
<site-packages>/executorch/include
```

Fixing this issue. Verified it on [build_torchao_ops.sh](https://github.com/pytorch/ao/blob/main/torchao/experimental/build_torchao_ops.sh)

Pull Request resolved: #6102

Reviewed By: lucylq

Differential Revision: D64189337

Pulled By: larryliu0820

fbshipit-source-id: 13033587f5499537623995b8f9457fb47d780340

* New Runtime pybind API (#6063)

Summary:
Based on this proposal: https://docs.google.com/document/d/10Q4-pt97inQQtFf-FjjwhMaDXXCfk1zGy6V6EkygNUY/edit#heading=h.fcrpnrtb6cud

Historically our pybinding APIs are not following the same C++ modeling
(Program, Method etc) and hence it's hard to use and easy to hit
footguns - for example, if we load the program and return it from a
python method, it goes out of the scope and releases the memory.

This effort is to create Pybind APIs that resembles C++ objects so it's
less confusing to the users.

Add the following python classes:
* `Runtime`: a singleton object hosting methods like `load_program`.
  Returns a `Program` object when calling `load_program`. Also exposes
  the operator registry
* `Program`: each pte file should have one `Program` object. Most
  important method is `load_method` which returns a `Method` object. It
  has a property `method_names` where we can inspect what methods are
  inside this .pte file.
* `Method`: one object per method name in a given `Program`. Exposes
  `execute` which takes in pytree flattened torch tensors as input and
  return pytree flattened output. It also exposes `MethodMeta` for users
  to inspect more information regarding input/output of this method.

Pull Request resolved: #6063

Reviewed By: dbort

Differential Revision: D64132360

Pulled By: larryliu0820

fbshipit-source-id: a2f35edc5fd8c200df0812a693e454d66d6a907e

* Lint

* Fix test_pybindings.py

---------

Co-authored-by: Riley Dulin <dulinr@meta.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dbort dbort dbort approved these changes

Assignees
No one assigned
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. fb-exported Merged
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@larryliu0820 @facebook-github-bot @dbort