I had problems with the imagenet_c++_user_threading example. It was getting stuck occasionally. Then I realized it’s because receive_output() could use a different stream from send_input because recvinf_label is uninitialized.
// Send the input data to the accelerator
accl->send_input(input_data, model_info.model_index, stream_label, 0);
// Receive the processed output from the accelerator
accl->receive_output(ofmap, model_info.model_index, recvinf_label, 0);
2nd, when creating MxAcclMT from a buffer, it insists on owning the buffer and freeing it when MxAcclMT is destroyed. Had to make a copy of the buffer as a work around. Can it not insist on freeing?
3rd issue is the MX::Runtime::MxAcclMT::run is missing in libmx_accl.so. There is a MX::Runtime::MxModel::manual_run
Other wise, your API & hardware is good and easy to use. Especially from not having to quantize/requantize the inputs and dequantize/requantize the outputs.
Hi, @SIMDgenius,
Thank you for your feedback!
If you’re using the downloadable files from the tutorial, you should see the recvinf_label integer declared on line 105 of classification_accl_c_user.cpp but not initialized; you are correct in pointing out that this is a bug, and the value should be initialized to 0 for a single-stream application. Some compilers will initialize the value automatically, but it’s absolutely best practice to initialize recvinf_label in the code. This could be the reason for the inconsistent behavior you observed. Thank you for pointing this out! We’ll work to get it resolved soon.
For your second question, creating an MxAcclMT object from a buffer requires the buffer to remain valid and accessible throughout the initialization phase. The continued ownership of said buffer by the MxAcclMT object until destruction is just the way we chose to implement the API, but this is behavior we plan to change in our upcoming release of SDK 2.2. In the downloadable code, we opt not to create the MxAcclMT object from a buffer and instead pass the path to the compiled DFP (see line 73).
To address the third issue about MX::Runtime::MxAcclMT::run being missing in libmx_accl.so, this function exists in our header files, but the implementation is missing in the packaged version of the release. Thank you for uncovering this issue! We will get this resolved as soon as we can, and we apologize for the inconvenience.
I hope these suggestions help to resolve your issues. If you find you are still facing trouble, we’ll be happy to assist you in further troubleshooting. Happy coding!
My issue with MxAcclMT owning the memory, is the buffer is in a container class, which owns the memory, so I was getting a double free crash.
Glad you will address these issues in a future release. The receive_output getting stuck issue took me a while to figure out given the random behavior. I have work arounds for them now.
1 Like