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

Slice python api #2932

Open
wants to merge 51 commits into
base: main
Choose a base branch
from
Open

Slice python api #2932

wants to merge 51 commits into from

Conversation

jjsjann123
Copy link
Collaborator

@jjsjann123 jjsjann123 commented Sep 11, 2024

Updating FusionDefinition.ops.slice to take dynamic Val as slice arguments. Three overload is supported:

  1. fd.ops.slice(T0, start=[S0, S1], end=[S2, S3])

  2. fd.ops.slice(T0, start=(S0, S1), end=(S2, S3))

  3. V0 = fd.define_vector(2)
    V1 = fd.define_vector(2)
    fd.ops.slice(T0, start=V0, end = V1)

Note that we currently don't yet support mixing the argument type, i.e. fd.ops.slice(T0, start=[S0, S1], end=V1) will error out.
Before this PR, slice requires all args to be constant python number. This PR allows us to have dynamic slice behavior, since we can use Val/Vector in slice now.

@rdspring1
Copy link
Collaborator

Do you have any plan to update the composite operation API at https://github.com/NVIDIA/Fuser/blob/main/csrc/ops/alias.h#L119-L136?

It only takes std::vector<int64_t> for the slice range instead of std::vector<Val*>.

@jjsjann123
Copy link
Collaborator Author

Do you have any plan to update the composite operation API at https://github.com/NVIDIA/Fuser/blob/main/csrc/ops/alias.h#L119-L136?

It only takes std::vector<int64_t> for the slice range instead of std::vector<Val*>.

Nope. I can just use the very first overload with std::vector<Slice>, that would support dynamic use case as well.

Val* start_idx = start.at(idx);
Val* end_idx = end.at(idx);
Val* stride_idx = stride.at(idx);
NVF_CHECK(
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

These checks are now inside finalizeDefinition instead of on the constructor. Hence exposes the issue on our FusionCache #2953

csrc/python_frontend/fusion_record.h Outdated Show resolved Hide resolved
csrc/python_frontend/python_bindings.cpp Show resolved Hide resolved
csrc/python_frontend/python_bindings.cpp Show resolved Hide resolved
csrc/python_frontend/python_bindings.cpp Show resolved Hide resolved
tests/python/test_python_frontend.py Show resolved Hide resolved
csrc/python_frontend/fusion_record.h Show resolved Hide resolved
Base automatically changed from fusion_cache_error_cache to main September 18, 2024 23:41
@jjsjann123
Copy link
Collaborator Author

!build

@jjsjann123
Copy link
Collaborator Author

!build

@jjsjann123
Copy link
Collaborator Author

!build

@jjsjann123
Copy link
Collaborator Author

!build

@jjsjann123
Copy link
Collaborator Author

!build

@jjsjann123
Copy link
Collaborator Author

!build

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.

3 participants