PLSDK-2597 - SSD_Multibox: updated to include slider for run-time probability modification - SSD_Multibox: skip grabbing frame input multiple times, as real-time would very based on multicore configuration and network complexity - SSD_Multibox: resize and central cropping added; instead of showing rectangles in original image, network input is presented - Classification: Toydogs configuration added including models Signed-off-by: Djordje Senicic <x0157990@ti.com>
Add jdetnet_voc network and make it the default - jdetnet_voc is trained with more object categories than original jdetnet. Make jdetnet_voc the default in the ssd example. User can still use command line options to run the original jdetnet network. - MCT-1091
Simplify API for multiple contexts 1. Simplify context API in ExecutionObject. Replace context_id variants to multiple existing APIs with these two APIs: bool AcquireAndRunContext(uint32_t& context_idx, int frame_idx, const IODeviceArgInfo& in, const IODeviceArgInfo& out); bool WaitAndReleaseContext(uint32_t context_idx); 2. The timing methods for host execution in EOPs and EOs: * GetProcessTimeInMilliSeconds() * GetHostProcessTimeInMilliSeconds() are no longer accurate with multiple contexts and pipelining. Replace these methods and replace with a generic timestamp based approach. There is a single API call to enable time stamps in an application: //! Enable time stamp generation for TIDL API events bool EnableTimeStamps(const std::string& file = "timestamp.log", size_t num_frames=32); If this method is called before TIDL API frame processing, the API will generate timestamps for events corresponding to each frame (e.g. EOP::ProcessFrameStartAsync, EOP::ProcessFrameWait, etc.). These timestamps are then written to file when the user's application completes. A separate script is used for post-processing the time stamps and generating data for the user. (MCT-1073, MCT-1074)
Updates to User's Guide and related examples Changes: * Overview chapter, includes a Terminology section. * Section on different use cases in the "Using the API" chapter. * Updated the Examples chapter to reflect new examples and AM5749 benchmarking. * Added the two_eo_per_frame_opt example to illustrate double buffering. (MCT-1043)
Video input option and document update - mp4/avi/mov as pre-recorded video input - camera as live video input, let user choose video input port # - refactor examples code - bookkeep each EO's device/host time inside EOP since EO could be shared - documentation update on 650MHz EVE - documentation on video inputs and output - MCT-1015
Report memory usage when device allocation fails TIDL API creates 2 device side heaps: 1. Parameter heap 2. Network heap The sizes of these heaps are specified in the Configuration object, via PARAM_HEAP_SIZE and NETWORK_HEAP_SIZE. Existing behavior: If the heaps are not large enough, allocation on the device triggers an assertion failure with no indication of how large the heaps need to be for successfull allocation. To improve the usability of the API, provide feedback to the user on the heap sizes required to satisfy device side allocations when any allocation fails. Also added `-Wall -Werror` when building examples and fixed failures. (MCT-1035)
ExecutionObjectPipeline for executing layersGroups - Add top level ExecutionObjectPipeline class to execute multiple layersGroups. - An ExecutionObjectPipeline is constructed from multiple ExecutionObjects, each ExecutionObject executes one layersGroup in the network, together they execute consecutive layersGroups. - Same look and feel as ExecutionObject, e.g. ProcessFrameStartAsync, ProcessFrameWait, GetInputBufferPointer, GetOutputBufferPointer - MCT-1017, MCT-1029