-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
[Hexagon]: Add upload function to hexagon session #13161
[Hexagon]: Add upload function to hexagon session #13161
Conversation
Thanks for contributing to TVM! Please refer to the contributing guidelines https://tvm.apache.org/docs/contribute/ for useful information and tips. Please request code reviews from Reviewers by @-ing them in a comment.
Generated by tvm-bot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the session-scoped uploads, and allowing tests to be reliant solely on the hexagon_session
instead of the hexagon_launcher
. This is a strictly better usage for a testing environment, where all state should be session-scoped. However, it doesn't allow for a production use case in which a model is uploaded once, and then run many times across many connections.
I'd propose the following design, which would allow for both use cases:
- A HexagonSession has a single workspace, which should be cleared when closing a session. Calls to
HexagonSession.upload
go into that session's workspace. Calls toHexagonSession.load_module
may only be atvm.runtime.Module
, and not astr
orpathlib.Path
, because persistent uploads are not supported. - A HexagonLauncher has a single workspace, which should be persistent across multiple connections to the same device. Calls to
HexagonLauncher.upload
go into the persistent workspace. Calls toHexagonLauncher.load_module
may be atvm.runtime.Module
, or astr
/pathlib.Path
to access previously uploaded artifacts.
This would be simplest to implement by having a upload
method in both HexagonLauncher
and HexagonSession
. Each would call a private method of HexagonLauncher
that takes an explicit workspace, but those workspaces would not otherwise be exposed to the user.
b7cb360
to
97384e8
Compare
6bd00a8
to
feb64c5
Compare
feb64c5
to
7f29069
Compare
Thank you, and the changes made address all the specific changes requested. I think the last item remaining is how the new design would support persistent artifacts stored on the hexagon device across multiple sessions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Following conversation with @mehrdadh , support for persistence across sessions to be re-added in a follow-up PR.
* [Hexagon]: Add upload to hexagon session * lint * fix typo * fix serial device skips * fix test on device * add serial device to rpc key * update error name * fix comment * move create_session to launcher * add is_simulator * lint * address Eric comment on Session object * rebase with main
* [Hexagon]: Add upload to hexagon session * lint * fix typo * fix serial device skips * fix test on device * add serial device to rpc key * update error name * fix comment * move create_session to launcher * add is_simulator * lint * address Eric comment on Session object * rebase with main
This PR adds
upload
to hexagon RPC server running on Hexagon side. This will remove the need ofadb
command for uploading/executing binary files on hexagon.