OpenVX 1.1 Specification: Vendor-specific implementation details broken down by section

Section 2.10.2: User Kernels Naming Conventions
- TI's vendor ID is VX_ID_TI
- TI user kernel strings begin with "com.ti"
- TI user kernel enums begin with TIVX_KERNEL_
- The ':' character is reserved in TI's implementation, so a user kernel shall not use a ':' as part of the kernel name string.
Section 2.12: Targets
- TI's targets can be found at <TIOVX_PATH>/include/TI/tivx.h
Section 2.18.1: Extending Attributes
- TI's vendor extension ID is VX_ID_TI
Section 2.18.2: Vendor Custom Kernels
- Further documentation is provided for any custom kernel extension
Section 2.18.3: Vendor Custom extensions
- TI does not currently support any custom extensions of the form mentioned in this section. See ti extensions as part of this API documentation.
Section 2.18.4: Hinting
- TI does not currently support any custom hints

TIVX Namespace Naming convention

TI's naming convention append "tivx" to the front of a given object. For example, a TI extension of the df_image_e is called "tivx_df_image_e".
TI's enumeration values append "TIVX" to the front of an enum. For example, a TI-specific target host is called TIVX_TARGET_HOST.

The TI Implementation of OpenVX supports the creation of a single context per process running on the host CPU. Additional calls to vxCreateContext beyond the initial call from that process will simply return a reference to the initially created context.
Furthermore, the TIVX_CONTEXT_MAX_OBJECTS does not take effect. It merely provides the value of the amount of contexts that are allowed per process, namely 1.

The valid regions for each kernel are set prior to graph verification and restrictions to valid regions are propagated to downstream kernels during the initialize callbacks of each kernel.
After graph verification, the valid regions for each kernel have been set.
Therefore, following graph verification, changes to the valid region using vxSetImageValidRectangle must not be made.

The following functions are used for mapping of specific data objects:
- vxMapArrayRange
- vxMapImagePatch
- tivxMapTensorPatch
The types of mapping supported for these functions are the following:
- VX_READ_ONLY
- VX_READ_AND_WRITE
- VX_WRITE_ONLY
The framework allows multiple mappings of the same region of a given data object.
Therefore, the user must be aware of the regions that have been mapped and the read/write privileges that each mapping has been granted.

Each tensor is mapped to a single contiguous buffer, of size = stride[number_of_dimensions - 1U] * dimensions[number_of_dimensions - 1U]

The user data objects included as a part of the OpenVX User Data Object Extension allow you to create an OpenVX data object from a custom data structure. If the custom data structure were to include OpenVX data objects itself, the framework would not be able to recognize this fact and thus would not allocate the data buffers corresponding to that data object and would not assign object descriptors to the references included in the structure. Also, these OpenVX data object handles are not recognized on remote targets due to the framework not performing memory pointer translation, as well as missing host APIs on remote cores. For expert users, this allocation and assignment could be done manually within the application, but it is not recommended.

The OpenVX 1.3 specification allows for required parameters to be NULL during create time as per the last paragraph in the below portion of the specification:
- https://www.khronos.org/registry/OpenVX/specs/1.3/html/OpenVX_Specification_1_3.html#sec_graph_verification
However, given that TI OpenVX supports the 1.1 specification, the required parameters must be non-NULL during create time.

The OpenVX 1.1 specification for vxRemoveKernel states that it returns a VX_FAILURE "If the application has not released all references to the kernel object OR if the application has not released all references to a node that is using this kernel OR if the application has not released all references to a graph which has nodes that is using this kernel."
The TI implementation is more relaxed than this and does not return VX_FAILURE due to any of these conditions. Instead, we make use of reference counting such that it is allowed to call this function prior to the application or other objects still retaining references. Calling vxRemoveKernel will mark the kernel to be removed when all references are released, either at the time of calling vxRemoveKernel, or at a later time in the application teardown process.
This removes a burden of order of releasing references from the application, and is carried by the framework, which is consistent with how other OpenVX objects are defined to work.

The OpenVX 1.1 specification for vxGetContext does not state the return value in the case that a vx_context is provided to this function
For TI's implementation of OpenVX 1.1, the vxGetContext will return the same vx_context supplied as a parameter to this function.

After creating a vx_object_array using vxCreateObjectArray and obtaining a vx_object_array element using vxGetObjectArrayItem, both the vx_object_array element and the vx_object_array itself must be released in order to avoid having a dangling reference when releasing the OpenVX context.
The order in which the vx_object_array and the vx_object_array elements are to be released is not mandated by the framework
A vx_object_array cannot have a vx_object_array as an exemplar. If this is attempted, the creation of the object array will return an error