Accelerators via executors in ITK

I have seen that Facebook (Niebler et al.) published an implementation about executors recently: libunifex.

I heard about executors from @matt.mccormick, I was thinking about the steps that ITK would need to implement to use this approach allowing an easier use of accelerators (GPU).
From my view the current GPUImage base class is a great example of plumbing opencl kernels into ITK infrastructure, but having to reimplement the filters for GPU, with a different class seems cumbersome. There have been little contributions of new GPUFilters since its inception.

Executors seems the C++ way to plumb in a scalable way accelerators with CPU.
I wonder though, what would be the optimal architecture for implementing it in ITK.
Right now ITK has single threaded code and optional multithread.
I guess one way would be to use a GenerateData like function, with option to call accelerators.
execute(single_thread), execute(multi_thread), execute(openCL).
So, I am guessing the work to transfer data and set up options for the accelerators would need to be done in the executors initialization, but this can be done once in a base class, and let the filter have functions specific to the different accelerators.

Just touching waters, but seems an interesting approach that would be standarized in C++ (23?) but usable with this third-party library from C++17.

Hola @phcerdan!

Yes, executors and quite exciting, providing the nice modern C++ interface, full support for lambda’s, etc, a nice (the best?) interface for working with accelerators, and the what promises to provide the best cross-hardware support in the future since it is part of the language standard.

We can learn from and build on the lessons and technology developed in the GPUFilters filters work. Primarily, the ability to re-use the CPU filter pipeline logic and the buffer management, preventing transfers to/from the accelerator, is nice.

In terms of global options like device selection, we may want to see what we can get by with using standard interfaces, then add options to an ITK singleton class as needed, then add overrides and additional options to an ITK executor base class instance.

The future is exciting :slight_smile: