Order of accumulate side effect


Accumulate Kernel modifies a second bidirectional parameter ‘accum’.
Who orders the side effect?

For example:

img0 = init..
img1 = init..

XXKernel = vxCreateNode(graph, kernelA)
AccKernel = vxCreateNode(graph, VX_KERNEL_ACCUMULATE);
YYKernel = vxCreateNode(graph, kernelB);

vxSetParameter(YYKerenl, 0, VX_INPUT, img1);
vxSetParameter(AccKernel, 0, VX_INPUT, img0);
vxSetParameter(XXKernel, 0, VX_INPUT, img1);
vxSetParameter(AccKernel, 1, VX_BIDIRECTIONAL, img1);

What value is observed by XXKernel and YYKernel?

  1. The modification is ordered by the first vxSetParameter call.
    XXKernel observes an accumulated img1 and YYKernel observes an original img1.

  2. The modification is ordered by the last vxSetParameter call.
    XXKernel and YYKernel observe an original img1.

  3. The modification is ordered by the vxCreateNode call.
    XXKernel observes original img1 and YYKernel observes an accumulated img1.

  4. undefined … ?


First, these code statements don’t call the functions themselves. They link the Nodes together. The order will be determined during the

status = vxVerifyGraph(graph);

call. The actual execution of the kernels won’t happen until

status = vxProcessGraph(graph);

So, refactoring your code example to show the issue:

vx_image images[] = {...};
vx_node nodes[] = {
    // assuming we have convenience create functions...
    vxCreateXXNode(graph, images[1], images[2]),
    vxCreateAccumNode(graph, images[0], images[1]),
    vxCreateYYNode(graph, images[1], images[3]),

vx_status status = vxVerifyGraph(graph); /* ordered here */
if (status == VX_SUCCESS)
    status = vxProcessGraph(graph); /* processed here */

The rule for ordering in a graph is always “writers before readers”. VX_BIDIRECTIONAL parameters are both, readers and writers, but for ordering purposes are considered writers first. In this example then, nodes[1] will execute first, followed by the other nodes.

Additionally, this also means that two or more accumulations to single reference (image here) are not allowed in a graph, as there would be multiple writers and thus in-determinant ordering. There could be two graphs to solve this issue that are called in series.

One could say that order of declaration should influence order of execution but OpenVX is designed to be declaration-order independent, only data-access dependent using the “writers before readers” ordering (and other rules).

So if the desired behavior here was to modify images[1] then accumulate into it, that would be prohibited, as that would violate the “multiple writers” rule. A separate graph would be needed to modify images[1] before the execution of this graph.

Thanks for your answer.
I got it.