Kernel parameters / data types

After successfully compiling the sample implementation I play around with it now. It is well-written and I like the overall concept. However, I am not sure if I have understood everything.

Are all the Kernels specifications final in respect to their supported data types or is this subject to change in a next spec release? E.g. the Intel Performance Primitives Library offers a set of different function prototypes for each Kernel.

What is the most convenient way if there is no Kernel available that supports the required data type or resolution? For example, the Phase Kernel is specified for vx_uint8 values, but the application requires a certain resolution of the atan2 function that fits only in a vx_uint16. Should all such Kernels be implemented in user extensions?

Is any kind of “intelligent” graph-builder supported or planned to to be supported? What I mean are techniques as known from DirectShow/MediaFoundation. If there are two incompatible nodes the graphbuilder would insert a transformation node automatically…

Thank you!

Are all the Kernels specifications final in respect to their supported data types or is this subject to change in a next spec release?

Final with respect to 1.0. 1.1, 1.2 may expand types. Since we use opaque objects, their internal typing (U8/U16) can be expanded (not replaced) and the API doesn’t change. vx_scalar, vx_image and others are designed for future compatibility in mind.

What is the most convenient way if there is no Kernel available that supports the required data type or resolution? For example, the Phase Kernel is specified for vx_uint8 values, but the application requires a certain resolution of the atan2 function that fits only in a vx_uint16. Should all such Kernels be implemented in user extensions?

Phase in particular is a mapping of -PI to PI using 0-255. There’s an equation in the spec which covers it. It’s not directly radians.

Is any kind of “intelligent” graph-builder supported or planned to to be supported? What I mean are techniques as known from DirectShow/MediaFoundation. If there are two incompatible nodes the graphbuilder would insert a transformation node automatically…

We didn’t want to add automatic conversion kernels for the specific reason that this is supposed to be a performance API, not an API which produces mysterious bottlenecks or extra steps when the developer may not expect this behavior. The graph already knows which nodes can connect or not (during vxVerifyGraph()) and will inform the developer. The sample has the ability to query a Node to find out what it’s interface is, vx_types and vx_direction and some other information. Specific information like U8 versus S16 is kept in the specification for now.

Thanks for your fast response!

[QUOTE=emrainey;30903]
Phase in particular is a mapping of -PI to PI using 0-255. [/QUOTE]

The Kernel I need would require a mapping to 0-0x4000 :frowning: I understand it would be hard to cover all possible parameters/mapping resolutions for a kernel…

[QUOTE=emrainey;30903]
We didn’t want to add automatic conversion kernels for the specific reason that this is supposed to be a performance API, not an API which produces mysterious bottlenecks or extra steps when the developer may not expect this behavior. [/QUOTE]

I fully agree!

In the presentation Elif Albuz did last month she mentioned a support for merging kernels. I found no hint for this in the specification or the sample implementation. Will this be eventually part of the standard or will it be up to the implementer of OpenVX to merge-magic in the vxVerifyGraph()?

In the presentation Elif Albuz did last month she mentioned a support for merging kernels. I found no hint for this in the specification or the sample implementation. Will this be eventually part of the standard or will it be up to the implementer of OpenVX to merge-magic in the vxVerifyGraph()?

Merging kernels is an implementor’s choice, but usually (though not always) will be triggered by the user’s usage of Virtual Data types.