If a kernel that has only one available target is instantiated, the vxSetNodeTarget() API does not have to be called for that instantiated kernel. It will default to the only available target.
If multiple targets are available for a given kernel and the vxSetNodeTarget() is not called, the framework will default to the first target added to the kernel via the tivxAddKernelTarget() API, which is called when adding the target kernel to the context.
vxGetRemapPoint() and vxSetRemapPoint()
The vxGetRemapPoint() and vxSetRemapPoint() API's must always get or set the (0,0) element first prior to any other get or set. Additionally, the element at (remap_width, remap_height) must be set or gotten last. This is because getting or setting the (0,0) element performs a map of the remap object and getting or setting the (remap_width, remap_height) element performs an unmap of the remap object.
Stride Alignment for Images and Raw Images
TIOVX automatically aligns the stride of images and raw images to the value of TIVX_DEFAULT_STRIDE_Y_ALIGN. This is a requirement of certain hardware accelerators (such as LDC) and should not be modified.
Graph Performance API's with pipelining
The graph performance API's (VX_GRAPH_PERFORMANCE) give the overall time to execute a graph.
However, when using the pipelining extension, this may not be as useful in the case that one may need to calculate the frame rate of the graph.
In this case, it is recommended to use the API's provided in vision_apps for calculating the frame rate and other performance information here
Enabling a node within the graph to run at lower FPS than rest of graph
In some situations, it may be desirable to have a node within the graph run at a lower FPS than the rest of the graph.
In these scenarios, the node itself can be customized using the steps below to accomplish this.
A thread can be created from the create callback of the custom node.
Pass message/control commands from this thread in process callback.
Close thread from destroy callback
This is done in the tivxHwaVpacVissNode to pass information to the tivxAewbNode and can be referenced for custom node implementations.
Virtual Object Support in TIOVX
While the OpenVX standard specification provides a provision for implementations to optimize memory footprint via virtual objects, the TIOVX framework does not provide any added optimization from using virtual objects.
Certain nodes, such as the DSS M2M node and the Mosaic node, do not support virtual objects. In these cases, the standard objects should be used instead.
Map and Copy API Usage in TIOVX
Each OpenVX data object has an associated vxMap<Data_Object> and vxCopy<Data_Object> API.
In general, all memory allocation within TIOVX occurs during the vxVerifyGraph call, in order to provide a single return regarding whether or not a system has sufficient memory to run applications. Therefore, even if the data object is created via the vxCreate<Data_Object> API, the memory will only be allocated at the call to vxVerifyGraph.
There are a few exceptions to this rule:
The vxMap<Data_Object> and vxCopy<Data_Object> API's are an exception to this rule about memory allocation occurring at a single point. Given that these API's return a pointer to the object data buffer, the memory for these data objects are allocated in the call to vxMap<Data_Object> and vxCopy<Data_Object>. When the call to vxVerifyGraph occurs, it will have already allocated this memory prior to executing the graph verification.
An important note about these API's is that the handles used by these API's must be allocated using tivxMemAlloc rather than by using malloc or other such memory.
TIOVX Implementation of Subimages
The OpenVX specification does not define the depth of the number of the subimages which a vx_image may contain
Therefore, the TIOVX implementation has added a max value of "2" for the number of subimage levels, as well as a max value of "16" for the number of subimages per level.
These are configurable and can be updated in the max value configuration file.