![]() |
VisionWorks Toolkit ReferenceDecember 18, 2015 | 1.2 Release |
VisionWorks takes the OpenVX programming model as base.
This section, summarizes the most important aspects of it. More details can be found in the OpenVX specification.
In order to safely manage destruction of objects, VisionWorks uses a reference counter mechanism. The application gets references to objects and can not destroy them directly. Instead, the destruction of an object is managed by the VisionWorks framework and occurs when the reference counter of the object reaches zero, meaning that this object is no longer needed by the application.
The life cycle of any object is then:
Data containers (such as vx_image
, vx_array
, ...) are opaque objects, therefore access to their data (such as image pixels, array elements, ...) must be requested explicitly by the application. The handle returned by the request must be released back to VisionWorks before further execution of any primitives that use the data object. This memory model allows VisionWorks to efficiently and safely manage the complex memory hierarchy of heterogeneous hardware systems. For instance, an image can be moved automatically across the system and the resynchronization with the application running on the CPU happens only when needed by the application.
Primitives can be executed in two ways :
vxu
or nvxu
) similar to the OpenCV or NPP execution mode. The immediate execution model is useful for one-time processing when the primitive setup overhead is not a big concern. It can also be useful as an intermediate step in application development, like when porting an application that uses OpenCV, for example.The VisionWorks API may be used from multiple threads, subject to restrictions. VisionWorks provides the following safety guarantees:
If two or more calls are made concurrently, then the following conditions must hold:
If either of the conditions fails to hold, then the behavior is undefined; otherwise, the effect of the calls is as if they have been made sequentially, in some unpredictable order.
Examples of valid concurrent calls follow.
Examples of invalid concurrent calls follow.
A host system (especially a desktop system) can have multiple GPU devices. The VisionWorks API can be used on such systems with some limitations.
A VisionWorks context is bound to a single device that is selected as current prior to VisionWorks context creation:
VisionWorks data objects are allocated on that device and all Vision primitives are executed on that device independently from the current device selection. VisionWorks API calls do not affect the current device selection:
To map VisionWorks data objects to CUDA memory space, the VisionWorks context's CUDA device must be selected as current prior to the access call; otherwise, the access call will fail.
Imported CUDA device memory must be allocated on the same device that was used for VisionWorks context initialization; otherwise, it leads to undefined behavior. That device must be selected as current when the import function is called.
The device that was selected as current prior to VisionWorks context creation can be obtained via vxQueryContext with NVX_CONTEXT_ATTRIBUTE_INITIAL_CUDA_DEVICE_ID.