 |
The OpenVX Specification
r31169
|
|
The OpenVX Specification
r31169
|
OpenVX is a low-level programming framework domain to enable software developers to efficiently access computer vision hardware acceleration with both functional and performance portability. OpenVX has been designed to support modern hardware architectures, such as mobile and embedded SoCs as well as desktop systems. Many of these systems are parallel and heterogeneous: containing multiple processor types including multi-core CPUs, DSP subsystems, GPUs, dedicated vision computing fabrics as well as hardwired functionality. Additionally, vision system memory hierarchies can often be complex, distributed, and not fully coherent. OpenVX is designed to maximize functional and performance portability across these diverse hardware platforms, providing a computer vision framework that efficiently addresses current and future hardware architectures with minimal impact on applications.
OpenVX contains:
OpenVX defines a C Application Programming Interface (API) for building, verifying, and coordinating graph execution, as well as for accessing memory objects. The graph abstraction enables OpenVX implementers to optimize the execution of the graph for the underlying acceleration architecture.
OpenVX also defines the vxu utility library, which exposes each OpenVX predefined function as a directly callable C function, without the need for first creating a graph. Applications built using the vxu library do not benefit from the optimizations enabled by graphs; however, the vxu library can be useful as the simplest way to use OpenVX and as first step in porting existing vision applications.
As the computer vision domain is still rapidly evolving, OpenVX provides an extensibility mechanism to enable developer-defined functions to be added to the application graph.
The purpose of this document is to detail the Application Programming Interface (API) for OpenVX.
The document contains the definition of the OpenVX API. The conformance tests that are used to determine whether an implementation is consistent to this specification are defined separately.
The section “Module Documentation” forms the normative part of the specification. Each API definition provided in that chapter has certain preconditions and post conditions specified that are normative. If these normative conditions are not met, the behavior of the function is undefined.
In this specification, the words shall or must express a requirement that is binding, should expresses design goals or recommended actions, and may expresses an allowed behavior.
The following typographical conventions are used in this specification.
Monospace words signify an API element (i.e., class, function, structure) or a filename.The following naming conventions are used in this specification.
vx_object, e.g., vx_image or vx_uint8, with an underscore separating the object name from the “vx” prefix.vx_struct_t, e.g., vx_imagepatch_addressing_t, with underscores separating the structure from the “vx” prefix and a “t” to denote that it is a structure.vx_enum_e, e.g., vx_type_e, with underscores separating the enumeration from the “vx” prefix and an “e” to denote that it is an enumerated value.vxsomeFunction() using camel case, starting with lowercase, and no underscores, e.g., vxCreateContext().Vision functions also have a naming convention that follows a lower-case, inverse dotted hierarchy similar to Java Packages, e.g.,
This minimizes the possibility of name collisions and promotes sorting and readability when querying the namespace of available vision functions. Each vision function should have a unique dotted name of the style: tld.vendor.library.function. The hierarchy of such vision function namespaces is undefined outside the subdomain “org.khronos”, but they do follow existing international standards. For OpenVX-specified vision functions, the “function” section of the unique name does not use camel case and uses underscores to separate words.
cl_kernel) to qualify a function written in “CL” which the OpenCL may invoke directly. This is close to the meaning OpenVX uses; however, OpenVX does not define a language.This specification would not be possible without the contributions from this partial list of the following individuals from the Khronos Working Group and the companies that they represented at the time:
1.8.7