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

Support loading non-string models from memory #107

Merged
merged 7 commits into from
May 17, 2024
Merged

Conversation

pnehrer
Copy link
Contributor

@pnehrer pnehrer commented May 16, 2024

We've run into an issue with Core::read_model_from_buffer -- the wrapper assumes that the in-memory model is a valid string. However, non-native models, such as ONNX, aren't valid strings. Attempting to load an ONNX model results in an error creating a CString due to non-terminating null characters.

We propose to change the method interface to support arbitrary byte models rather than just strings.

Furthermore, we propose to make the weight tensor an optional argument, as it doesn't apply to non-native models.

@pnehrer pnehrer marked this pull request as draft May 16, 2024 17:33
@pnehrer pnehrer marked this pull request as ready for review May 16, 2024 18:30
Copy link
Contributor

@abrown abrown left a comment

Choose a reason for hiding this comment

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

Thanks for the contribution; I think it makes sense. Can you fix the one comment below before I merge?

model_str: &str,
weights_buffer: &Tensor,
model_str: &[u8],
weights_buffer: T,
Copy link
Contributor

Choose a reason for hiding this comment

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

I propose we move back to the Option<&Tensor> like you had; it's a bit more straightforward and avoids potential concerns with code size, etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good 👍

@abrown
Copy link
Contributor

abrown commented May 17, 2024

Oh, and one other thing: the CI failures are not due to this change. I think you will have to rebase to see CI turn green.

@pnehrer
Copy link
Contributor Author

pnehrer commented May 17, 2024

Oh, and one other thing: the CI failures are not due to this change. I think you will have to rebase to see CI turn green.

I think this is a function that isn't in 2022.3.0, which is what seems to be failing to link. Some more recent version jobs do succeed before this one cancels the rest.

@pnehrer
Copy link
Contributor Author

pnehrer commented May 17, 2024

Oh, and one other thing: the CI failures are not due to this change. I think you will have to rebase to see CI turn green.

I think this is a function that isn't in 2022.3.0, which is what seems to be failing to link. Some more recent version jobs do succeed before this one cancels the rest.

... and as a result, I can remove the unit test if that helps.

@abrown
Copy link
Contributor

abrown commented May 17, 2024

Ah, I see: @rahulchaphalkar and I noticed a failure in the Windows builds due to the missing function and I chalked it up to some difference between the Windows and Linux releases. But actually we were never exercising the function so it would have failed if someone actually tried it. Given that, I propose we keep the test and remove the following step in CI since we just can't support those versions with this function:

# APT install and check oldest supported version 2023.2.0
include:
- os: ubuntu-22.04
version: 2022.3.0
apt: false

With that out of the way, I think this should be good to go 🤞

@pnehrer
Copy link
Contributor Author

pnehrer commented May 17, 2024

Would you still want to keep the "oldest supported version" with apt and just pull it up to 2023.2.0, instead of removing that combo altogether?

@abrown
Copy link
Contributor

abrown commented May 17, 2024

Would you still want to keep the "oldest supported version" with apt and just pull it up to 2023.2.0, instead of removing that combo altogether?

Well, we have 2023.2.0 up above in the non-APT build so I'm not too worried about it.

@abrown abrown merged commit 1aacdf9 into intel:main May 17, 2024
15 checks passed
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