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

Halide Python Extensions need more control over Runtime #6956

Open
1 of 2 tasks
steven-johnson opened this issue Aug 22, 2022 · 1 comment
Open
1 of 2 tasks

Halide Python Extensions need more control over Runtime #6956

steven-johnson opened this issue Aug 22, 2022 · 1 comment
Assignees
@steven-johnson
Labels
enhancement New user-visible features or improvements to existing features. python Issues related to Halide/Python interop release_notes For changes that may warrant a note in README for official releases.

Comments

@steven-johnson
Copy link
Contributor

steven-johnson commented Aug 22, 2022 •
edited
Loading

Currently, if you build and package Halide code as a Python extension, we default to embedding a single Halide Runtime in each extension, with all symbols hidden. This is suboptimal in at least a couple of ways:

  • There is currently no Python API for anything in HalideRuntime.h; while some of these are certainly moot (e.g. overriding halide_alloc), others are essential and really need to be exposed (e.g. device_sync).
  • If you need to share a HalideRuntime between multiple Halide-generated functions in Python, they must be packaged together in a single extension. At a minimum, we should try to make this simple to do (e.g. adding support to this to the CMake rules, and/or a helper script for other build systems). (It would be preferable if we could somehow designate the HalideRuntime globals from multiple extensions to be "shared" somehow, but this would require a fairly significant refactoring of our Runtime and of how it allocates and manages globals.)
@steven-johnson steven-johnson added enhancement New user-visible features or improvements to existing features. python Issues related to Halide/Python interop labels Aug 22, 2022
@steven-johnson steven-johnson self-assigned this Aug 22, 2022
@steven-johnson
Copy link
Contributor Author

An interesting wrinkle here is that a lot of the things you'd think need to be exposed (e.g. device_sync) are currently useless: the Python bindings don't actually provide halide_buffer_t, believe it or not; we rely on thin bindings around the Python Buffer protocol. This is great for interop, but (as per #6868) means that currently, all AOT code called from Python is 'host-only' for input and output, so there is always an implicit device_sync before and after each call. Useful implementation of this class of runtime calls really needs off-host buffer capability before it can be implemented (or even designed) properly.

steven-johnson added a commit that referenced this issue Aug 27, 2022
@steven-johnson
Add add_halide_python_extension_library() rule
1b8323e 
This adds a rule to create a single Python extension library from one (or more) halide_library rules. This allows you to package multiple Halide filters into a single Python module, which is nice because (1) being able to organize is good, and (2) all the filters in a single Python extension module share the same Halide runtime, including (e.g.) thread pools and method overrides.

(It also removes the just-recently-added PYTHON_EXTENSION_LIBRARY option from the add_halide_library rule, as this new rule is better and more flexible in pretty much every way.)

This modifies the content of our `python_extension` output in such a way that existing uses should be completely unaffected, but defining the right preprocessor macros allows us to split the function wrappers up from the method-definition declaration, so we don't have to generate any new code artifiacts to make this work.

Partially addresses #6956.
@steven-johnson steven-johnson mentioned this issue Aug 27, 2022
Merged
@steven-johnson steven-johnson added the release_notes For changes that may warrant a note in README for official releases. label Aug 29, 2022
steven-johnson added a commit that referenced this issue Aug 29, 2022
@steven-johnson
Add add_halide_python_extension_library() rule (#6979)
c24b406 
* Add add_halide_python_extension_library() rule

This adds a rule to create a single Python extension library from one (or more) halide_library rules. This allows you to package multiple Halide filters into a single Python module, which is nice because (1) being able to organize is good, and (2) all the filters in a single Python extension module share the same Halide runtime, including (e.g.) thread pools and method overrides.

(It also removes the just-recently-added PYTHON_EXTENSION_LIBRARY option from the add_halide_library rule, as this new rule is better and more flexible in pretty much every way.)

This modifies the content of our `python_extension` output in such a way that existing uses should be completely unaffected, but defining the right preprocessor macros allows us to split the function wrappers up from the method-definition declaration, so we don't have to generate any new code artifiacts to make this work.

Partially addresses #6956.

* Omits -D in target_compile_definitions

* be explicit about setting to empty

* Add quotes

* Add comments re BUILD_INTERFACE

* Add MODULE_NAME comment

* Remove "defined in HalideGeneratorHelpers.cmake"

* Add comment re add_halide_runtime()

* osx, macos, darwin, oh m

* blankity blank blank

* Use OBJECT library instead

* Add comment about X-macros

* Update HalideGeneratorHelpers.cmake
ardier pushed a commit to ardier/Halide-mutation that referenced this issue Mar 3, 2024
@steven-johnson @ardier
Add add_halide_python_extension_library() rule (halide#6979)
5b31623 
* Add add_halide_python_extension_library() rule

This adds a rule to create a single Python extension library from one (or more) halide_library rules. This allows you to package multiple Halide filters into a single Python module, which is nice because (1) being able to organize is good, and (2) all the filters in a single Python extension module share the same Halide runtime, including (e.g.) thread pools and method overrides.

(It also removes the just-recently-added PYTHON_EXTENSION_LIBRARY option from the add_halide_library rule, as this new rule is better and more flexible in pretty much every way.)

This modifies the content of our `python_extension` output in such a way that existing uses should be completely unaffected, but defining the right preprocessor macros allows us to split the function wrappers up from the method-definition declaration, so we don't have to generate any new code artifiacts to make this work.

Partially addresses halide#6956.

* Omits -D in target_compile_definitions

* be explicit about setting to empty

* Add quotes

* Add comments re BUILD_INTERFACE

* Add MODULE_NAME comment

* Remove "defined in HalideGeneratorHelpers.cmake"

* Add comment re add_halide_runtime()

* osx, macos, darwin, oh m

* blankity blank blank

* Use OBJECT library instead

* Add comment about X-macros

* Update HalideGeneratorHelpers.cmake
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@steven-johnson steven-johnson

Labels
enhancement New user-visible features or improvements to existing features. python Issues related to Halide/Python interop release_notes For changes that may warrant a note in README for official releases.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@steven-johnson