cconvey commented on code in PR #12727:
URL: https://github.com/apache/tvm/pull/12727#discussion_r967850860
##########
src/runtime/hexagon/hexagon_device_api.h:
##########
@@ -45,11 +45,27 @@ class HexagonDeviceAPI final : public DeviceAPI {
static HexagonDeviceAPI* Global();
//! \brief Constructor
- HexagonDeviceAPI() {}
+ HexagonDeviceAPI() { hexbuffs = std::make_unique<HexagonBufferManager>(); }
//! \brief Destructor
~HexagonDeviceAPI() {}
+ //! \brief Creates resource managers for the runtime
+ void AcquireResources() {
+ if (!hexbuffs->empty()) {
+ LOG(INFO) << "hexbuffs was not empty in AcquireResources";
Review Comment:
_Disclaimer: I've only looked briefly at the PR, so this question might be
off-base._
Depending on the intended lifespan of these allocations, would it be
possible to move the allocation / deallocation logic into code that runs on the
SoC? E.g., into `tvm_rpc_android`?
I could imagine a few benefits to this:
- Depending on which resources we're talking about, some might be
automatically freed by the SoC/Hexagon when the process is terminated. So even
if the host never has an opportunity to perform cleanup work, the Hexagon
resources still are released.
I'm thinking in particular about cases where the Hexagon code crashes or
returns an error. `tvm_rpc_server` either knows about the error, or (maybe?)
`tvm_rpc_server` crashes as well.
- Depending on the particular lifespans and automated-cleanup logics
involved, we might never need to explicitly release certain resources. E.g.,
the way Linux processes don't need to explicitly close their open file
descriptors before terminating.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@tvm.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
