# Do we want to support GPU backend in the SMPTools?

**URL:** <https://discourse.vtk.org/t/do-we-want-to-support-gpu-backend-in-the-smptools/5802>\
**Category:** Development\
**Created:** [May 18, 2021, 11:16am UTC](https://discourse.vtk.org/t/do-we-want-to-support-gpu-backend-in-the-smptools/5802 "2021-05-18T11:16:56Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Timothee\_Couble](https://discourse.vtk.org/user_avatar/discourse.vtk.org/timothee_couble/32/3086_2.png) [@Timothee\_Couble](https://discourse.vtk.org/u/Timothee_Couble)\
**Post date:** [May 18, 2021, 11:16am UTC](https://discourse.vtk.org/t/do-we-want-to-support-gpu-backend-in-the-smptools/5802/1 "2021-05-18T11:16:56Z")

</div>

Hi everyone,

We are currently trying to integrate VTKm as a new SMPTools backend with @Charles_Gueunet. ([MR-7823](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7823)).

We realized we couldn’t use the “standard” version of VTKm (with GPU backends) for this work. The GPU backends can’t use mechanisms such as pointer dereferencing and access to random iterators which are needed in some SMPTools functions. (e.g in `vtkSMPTools::Transform` and `vtkSMPTools::Fill` support non indexed arrays such as `std::map` and `std::set`).

After some reflection we wondered why the SMPTools doesn’t support GPU whereas the name SMP would suggest it does. Moreover we could technically support it through VTKm (the idea here is not to add a new GPU backend) and allow us to use the full potential of VTKm GPU backends.

But it may be incompatible with the current implementation of `Transform` and `Fill` and with some recent new suggestions (e.g. add `std::map` and `std::set` support for `vtkSMPTools::For()` @Yohann_Bearzi).

Finally if we don’t want to support the GPU backends we need to find a way to only use the CPU version of VTKm, one of them would be to compile twice VTKm: one for vtk algorithms and the other for the smptools (with CPU backends only). But as VTKm is quite long to compile it wouldn’t be perfect.

What future for the SMP tools, to become vtkMultiThreadTools, or to handle GPU with the according constraints?

---

<div class="post-metadata">

**Author:** ![mwestphal](https://discourse.vtk.org/user_avatar/discourse.vtk.org/mwestphal/32/19_2.png) [@mwestphal](https://discourse.vtk.org/u/mwestphal)\
**Post date:** [May 18, 2021, 11:40am UTC](https://discourse.vtk.org/t/do-we-want-to-support-gpu-backend-in-the-smptools/5802/2 "2021-05-18T11:40:38Z")

</div>

Yes, most definitely, ideally using VTKm.

---

<div class="post-metadata">

**Author:** ![Yohann\_Bearzi](https://discourse.vtk.org/user_avatar/discourse.vtk.org/yohann_bearzi/32/671_2.png) [@Yohann\_Bearzi](https://discourse.vtk.org/u/Yohann_Bearzi)\
**Post date:** [May 18, 2021, 12:37pm UTC](https://discourse.vtk.org/t/do-we-want-to-support-gpu-backend-in-the-smptools/5802/3 "2021-05-18T12:37:05Z")

</div>

When you say that the GPU backend can’t do pointer dereferencing, does it mean that if you have a VTK pointer attribute (a `vtkDataArray*` for instance) in your functor, you will not be able to use VTKm?

If there is a reliable way to know at compile-time what functors / SMP calls are unable to use VTKm as a backend, with some meta-programmation, you might be able to turn on / off the backend if VTK is compiled with VTKm?

Your remarks just made me think about something else. What happens if a functor uses standard library containers internally, such as `std::vector`? I know that CUDA doesn’t support those yet, though they will at some point. Is there a mechanism in VTKm to translate those containers into something the GPU can understand, or is this another constraint?

---

<div class="post-metadata">

**Author:** ![Yohann\_Bearzi](https://discourse.vtk.org/user_avatar/discourse.vtk.org/yohann_bearzi/32/671_2.png) [@Yohann\_Bearzi](https://discourse.vtk.org/u/Yohann_Bearzi)\
**Post date:** [May 18, 2021, 12:48pm UTC](https://discourse.vtk.org/t/do-we-want-to-support-gpu-backend-in-the-smptools/5802/4 "2021-05-18T12:48:12Z")

</div>

> If there is a reliable way to know at compile-time what functors / SMP calls are unable to use VTKm as a backend, with some meta-programmation, you might be able to turn on / off the backend if VTK is compiled with VTKm?

Oh I just realized that this makes the default backend choice a problem. We don’t want to have `std::thread` as the default backend when VTKm fails to use the GPU. And tbh, compiling VTKm twice (one for the CPU, and one for the GPU) seems horrific compile-time-wise…

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)\
**Post date:** [May 18, 2021, 1:34pm UTC](https://discourse.vtk.org/t/do-we-want-to-support-gpu-backend-in-the-smptools/5802/5 "2021-05-18T13:34:36Z")

</div>

Can this _please_ be done _after_ supporting runtime SMP backend selection? Then the new SMP backend can live in a new module without making everything have to wait for VTK-m to compile in such a build. Right now (unless I’m remembering incorrectly), any SMP implementation must live in `VTK::CommonCore`. If we’re adding GPU support in this way, it’s going to lose its “core”-ness really quickly (though one could argue it already has many things which aren’t “core” anyways, I’d like to avoid piling even more in).

---

<div class="post-metadata">

**Author:** ![dgobbi](https://discourse.vtk.org/user_avatar/discourse.vtk.org/dgobbi/32/18_2.png) [@dgobbi](https://discourse.vtk.org/u/dgobbi)\
**Post date:** [May 18, 2021, 2:37pm UTC](https://discourse.vtk.org/t/do-we-want-to-support-gpu-backend-in-the-smptools/5802/6 "2021-05-18T14:37:38Z")

</div>

The following statement confuses me. How does SMP imply GPU?

> [@Timothee\_Couble](#):
>
> After some reflection we wondered why the SMPTools doesn’t support GPU whereas the name SMP would suggest it does.

I usually think of parallel computing as being one of the following architectures:

1. traditional job submission systems like SLURM and SGE (grid computing)
2. message-passing interfaces, like VTK’s MPI-based parallelism across nodes
3. symmetric multi-processing, which strongly implies _shared memory_
4. GPU processing, where the processing does _not_ occur in system memory

My understanding is that SMP and GPU are different architectures for parallelism. When I do SMP, I expect that it will at least _appear_ as if the processing occurs in system memory.

---

<div class="post-metadata">

**Author:** ![Charles\_Gueunet](https://discourse.vtk.org/user_avatar/discourse.vtk.org/charles_gueunet/32/239_2.png) [@Charles\_Gueunet](https://discourse.vtk.org/u/Charles_Gueunet)\
**Post date:** [May 18, 2021, 4:16pm UTC](https://discourse.vtk.org/t/do-we-want-to-support-gpu-backend-in-the-smptools/5802/7 "2021-05-18T16:16:55Z")

</div>

You are right, SMP does not imply GPU, I might have misled Timothée here.So the argument about the name does not stand.

---

<div class="post-metadata">

**Author:** ![dgobbi](https://discourse.vtk.org/user_avatar/discourse.vtk.org/dgobbi/32/18_2.png) [@dgobbi](https://discourse.vtk.org/u/dgobbi)\
**Post date:** [May 18, 2021, 5:00pm UTC](https://discourse.vtk.org/t/do-we-want-to-support-gpu-backend-in-the-smptools/5802/8 "2021-05-18T17:00:16Z")

</div>

I’m still unclear on the whole _concept_ of a GPU back-end for vtkSMPTools. When you pass a functor to vtkSMPTools::For(), the functor will in general contain compiled C++ code (compiled for the CPU, not for the GPU). Machine code that has been compiled for the CPU cannot run on the GPU.

I agree that it is possible to write functors for the GPU, but that is a special case, not the general case. All the filters in VTK that use vtkSMPTools use functors that are compiled for the CPU. Adding a GPU back-end won’t magically make CPU code run on the GPU.