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

[serialization] Add Halide version and serialization version in serialization format #7905

Merged
merged 9 commits into from
Nov 30, 2023

Conversation

TH3CHARLie
Copy link
Contributor

Add Halide version string and serialization version string as part of the format. The halide version records the halide build under which the pipeline is serialized, a pipeline generated under an older Halide build could be compatible with a newer one, but we generate a user warning. The serialization version reflects any changes in the format itself, if the serialization version string does not match then it must be incompatible so we issue an error.

We also discussed adding a target string into the format as well, but we only know the target when we realize the pipelines (i.e. when calling realize) so I'm not sure what's the best way to obtain a reasonable target string here.

@derek-gerstmann
Copy link
Contributor

Actually the target is required when we serialize too (eg when they are exported from generators) … it may be a default no-arch, no-platform, but it should be included in the header

@TH3CHARLie
Copy link
Contributor Author

Actually the target is required when we serialize too (eg when they are exported from generators) … it may be a default no-arch, no-platform, but it should be included in the header

Now we don't ask for target explicitly during serialization. Maybe we serialize a "host" equivalent target string?

@derek-gerstmann
Copy link
Contributor

Actually the target is required when we serialize too (eg when they are exported from generators) … it may be a default no-arch, no-platform, but it should be included in the header

Now we don't ask for target explicitly during serialization. Maybe we serialize a "host" equivalent target string?

Yes, I think we should allow the target to be specified during serialization (so that generators which are evaluated for a specific target can indicate that the schedule is only appropriate for the chosen target), and default to something like no-arch, no-platform (meaning it is independent from the cpu/os).

We should probably also consider storing any autoscheduler that was used and it’s params.

@steven-johnson
Copy link
Contributor

Broken for Makefile builds because HALIDE_SERIALIZATION_VERSION_MAJOR and friends aren't defined there

@steven-johnson
Copy link
Contributor

Broken for Makefile builds because HALIDE_SERIALIZATION_VERSION_MAJOR and friends aren't defined there

fix pushed

@steven-johnson steven-johnson merged commit 3136819 into main Nov 30, 2023
19 checks passed
@steven-johnson steven-johnson deleted the xuanda/hlpipe-update branch November 30, 2023 17:59
ardier pushed a commit to ardier/Halide-mutation that referenced this pull request Mar 3, 2024
…lization format (halide#7905)

* halide version

* serialization version

* format

* Fix Makefile

* trigger buildbots

---------

Co-authored-by: Andrew Adams <[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.

4 participants