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.

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

[api] Promote Internal::Parameter to Halide::Parameter #7829

Merged
merged 9 commits into from
Sep 18, 2023

Conversation

derek-gerstmann
Copy link
Contributor

As per the discussion regarding refactoring the Serialization API:
#7760

Copy link
Contributor

@steven-johnson steven-johnson left a comment

Choose a reason for hiding this comment

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

From a quick skim, it looks like this change is simpy moving it into the right namespace -- we also need to take a close look at the methods that Parameter exposes (including the ctors); IMHO we want to prune it down to the bare minimum we think are necessary (enforcing via friend access if necessary), because otherwise we'll end up with a lot of weird usage we didn't expect (https://www.hyrumslaw.com/).

Once that is done, we will also need to provide a proper Python wrapper for the resulting API; the current Python wrapper (in PyParam.cpp) is deliberately a bare-minimum wrapper that was put in place only for some internal use, but with Parameter become a public Halide object, we need to ensure the Python wrapper provides the same.

@derek-gerstmann
Copy link
Contributor Author

derek-gerstmann commented Sep 1, 2023

From a quick skim, it looks like this change is simpy moving it into the right namespace -- we also need to take a close look at the methods that Parameter exposes (including the ctors); IMHO we want to prune it down to the bare minimum we think are necessary (enforcing via friend access if necessary), because otherwise we'll end up with a lot of weird usage we didn't expect (https://www.hyrumslaw.com/).

Once that is done, we will also need to provide a proper Python wrapper for the resulting API; the current Python wrapper (in PyParam.cpp) is deliberately a bare-minimum wrapper that was put in place only for some internal use, but with Parameter become a public Halide object, we need to ensure the Python wrapper provides the same.

Agreed. I intentionally left obvious internal methods (like remove_self_references and restore_self_references) hidden, but I didn't got so far as to change the class interface, since I wasn't entirely sure of the impact. Note also that ParameterContents remains internal as well.

protected.

Make Pipeline and Serializer protected friend classes.
@derek-gerstmann
Copy link
Contributor Author

I made the raw_buffer(), scalar_address(), and scalar_raw_value() access methods protected, and added Pipeline and Serializer as protected friends.

I believe these are the only potentially controversial class methods which expose addresses and internal values.

Copy link
Contributor

@steven-johnson steven-johnson left a comment

Choose a reason for hiding this comment

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

LGTM but I think we need to also flush out the Python wrapper for Parameter -- as mentioned elsewhere, the Python wrapper is currently just a minimal stub for internal use, but with this change, we need to promote it to full public status, and provide all the public methods in Python as well as C++.

src/Generator.cpp Show resolved Hide resolved
@derek-gerstmann
Copy link
Contributor Author

LGTM but I think we need to also flush out the Python wrapper for Parameter -- as mentioned elsewhere, the Python wrapper is currently just a minimal stub for internal use, but with this change, we need to promote it to full public status, and provide all the public methods in Python as well as C++.

Should we update the python bindings in this PR or open a new one?

@steven-johnson
Copy link
Contributor

LGTM but I think we need to also flush out the Python wrapper for Parameter -- as mentioned elsewhere, the Python wrapper is currently just a minimal stub for internal use, but with this change, we need to promote it to full public status, and provide all the public methods in Python as well as C++.

Should we update the python bindings in this PR or open a new one?

Unless there is an urgent reason we need to land this quickly, I think it would be better to work out the Python bindings in this PR as well; I've found it a useful exercise in the past to winnow out the calls that are actually necessary for the public API from the ones that aren't.

Derek Gerstmann added 2 commits September 15, 2023 11:34
Remove old stub internal interface from PyParam.
Copy link
Contributor

@steven-johnson steven-johnson left a comment

Choose a reason for hiding this comment

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

LGTM pending green

python_bindings/src/halide/halide_/PyParameter.cpp Outdated Show resolved Hide resolved
@steven-johnson
Copy link
Contributor

LGTM

@steven-johnson steven-johnson merged commit 68a0341 into main Sep 18, 2023
3 checks passed
@steven-johnson steven-johnson deleted the dg/api_make_parameter_public branch September 18, 2023 17:09
ardier pushed a commit to ardier/Halide-mutation that referenced this pull request Mar 3, 2024
* Promote Internal::Parameter to Halide::Parameter (to support Serialization API
refactoring)

* Make raw_buffer(), scalar_address(), and scalar_raw_value() methods
protected.

Make Pipeline and Serializer protected friend classes.

* Add Parameter public interface to python bindings.
Remove old stub internal interface from PyParam.

* Remove blank line at start of function

---------

Co-authored-by: Derek Gerstmann <[email protected]>
Co-authored-by: Steven Johnson <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants