[SYCL] Define interop type for images in Level-Zero and OpenCL backends

[mikhail-nikolskiy]

Currently interop type defined for buffers only.
Tests: llvm-test-suite#252

[romanovvlad]

LGTM, @alexbatashev could you please take a look as well?

[alexbatashev]

I think we agreed with @smaslov-intel we want to retire interop struct in favor of backend_traits.

[mikhail-nikolskiy]

Tests instability fixed in test code by replacing '&' with '=' in interop_task lambda - copy accessor objects by value, not by reference. Otherwise accessor could be destroyed before interop_task starts.

[smaslov-intel]

accessor could be destroyed before interop_task starts

The accessor should stay alive until it goes out of scope. I don't understand why this early destruction was possible.
If it is truly something that's going on then we should have it explained to the users in some form.

[alexbatashev]

accessor could be destroyed before interop_task starts

The accessor should stay alive until it goes out of scope. I don't understand why this early destruction was possible.
If it is truly something that's going on then we should have it explained to the users in some form.

If I'm not mistaken, interop tasks run in a separate thread. Tagging @s-kanaev

[s-kanaev]

If I'm not mistaken, interop tasks run in a separate thread.

There're two kinds of interop tasks:

• the ones launched with cl::handler::interop_task()
• host tasks with interop

The former are executed within the enqueueing thread.
The latter ones are executed in a distinct thread belonging to thread pool. See queue_impl::initHostTaskAndEventCallbackThreadPool(). Though the method is available in any queue, it's called only for default host queue.

[romanovvlad]

@mikhail-nikolskiy Could you please apply clang-format suggestion?

[smaslov-intel]

The former are executed within the enqueueing thread.

So how could accessors be destroyed earlier that the interop_task is completed?
intel/llvm-test-suite@df07c9e#diff-bf582222f4ea3305ae98fd3a169c8bdbb8ff7df2782592610154ced2d0edf6feR43

[s-kanaev]

So how could accessors be destroyed earlier that the interop_task is completed?

We've got two lambdas here:

• the one passed to queue::submit, lets call it command group handler lambda
• the one passed to handler::interop_task, lets call it interop task lambda

Now, the accessor is created in command group handler lambda and referred to in interop task lambda. Though, upon call to handler::interop_task the interop lambda doesn't get to be executed. It's only stored. The enqueue process is started after command group handler lambda finishes, i.e. it returns and all its local objects got destroyed. Interop lambda is executed only whilst enqueue process.

[mikhail-nikolskiy]

@mikhail-nikolskiy Could you please apply clang-format suggestion?
done

[smaslov-intel]

Now, the accessor is created in command group handler lambda and referred to in interop task lambda. Though, upon call to handler::interop_task the interop lambda doesn't get to be executed. It's only stored. The enqueue process is started after command group handler lambda finishes, i.e. it returns and all its local objects got destroyed. Interop lambda is executed only whilst enqueue process.

Thanks for explaining this non-obvious behavior!
I think this may be a big source of user errors in future.
Is there a chance to give a compile-time error by building this knowledge into FE?