Build Python wheels with SMP tools for runtime backend selection

user27182 · February 3, 2026, 8:48pm

According to the build settings:

Users can set:

VTK_SMP_IMPLEMENTATION_TYPE (default Sequential): Set which SMPTools will be implemented by default. Must be either Sequential, STDThread, OpenMP or TBB. The backend can be changed at runtime if the desired backend has his option VTK_SMP_ENABLE_<backend_name> set to ON.

I don’t think this is enabled for the Python wheel builds that VTK releases. I suspect that Sequential is used by default for compatibility reasons, which is OK, but then does it make sense to otherwise build with the backends such that users can select a backend at runtime?

VTK_SMP_ENABLE_STDThread: ON
VTK_SMP_ENABLE_OpenMP: ON
VTK_SMP_ENABLE_TBB: ON

There seems to be technical reasons for why this is not done (see links below), but it would be nice for Python users in particular to be able to make use of the performance boost using the VTK wheels published on PyPI.

https://gitlab.kitware.com/vtk/vtk/-/issues/18668

If this should be tracked as a feature request, let me know and I’ll create an issue in GitLab.

akaszynski · February 4, 2026, 3:04am

BTW, I built manylinux2014 compatible wheels with TBB enabled (by default) by following:

github.com/pyvista/pyvista-wheels

Build VTK with TBB

opened 10:04PM - 02 Feb 26 UTC

akaszynski

This is mostly how to build TBB compatible wheels on `manylinux2024`: ```bash #…!/usr/bin/env bash set -e mkdir -p build cd build yum install -y ninja-build cmake wget # could also try https://github.com/uxlfoundation/oneTBB/releases/v2021.1.1 wget https://github.com/uxlfoundation/oneTBB/releases/download/v2020.3/tbb-2020.3-lin.tgz tar xf tbb-2020.3-lin.tgz -C /opt # fairly sure that LD_LIBRARY_PATH lets auditwheel find tbb, but you might be able to get away without it export TBB_ROOT=/opt/tbb export LD_LIBRARY_PATH=/opt/tbb/lib/intel64/gcc4.8:$LD_LIBRARY_PATH get_python_bin() { local version="$1" echo "/opt/python/cp${version//.}-cp${version//.}/bin/python" } PYBIN=$(get_python_bin "3.12") cmake -GNinja \ -DVTK_SMP_IMPLEMENTATION_TYPE=TBB \ -DCMAKE_PREFIX_PATH=/opt/tbb \ -DCMAKE_BUILD_TYPE=Release \ -DVTK_BUILD_TESTING=OFF \ -DVTK_BUILD_DOCUMENTATION=OFF \ -DVTK_BUILD_EXAMPLES=OFF \ -DVTK_MODULE_ENABLE_VTK_PythonInterpreter:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_WebCore:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_WebGLExporter:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_WebPython:STRING=NO \ -DVTK_WHEEL_BUILD=ON \ -DVTK_MODULE_ENABLE_VTK_CommonArchive:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_DomainsMicroscopy:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_FiltersONNX:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_FiltersOpenTURNS:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_FiltersReebGraph:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_IOADIOS2:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_IOAlembic:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_IOFFMPEG:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_IOGDAL:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_IOLAS:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_IOMySQL:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_IOODBC:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_IOOpenVDB:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_IOPDAL:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_IOPostgreSQL:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_InfovisBoost:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_InfovisBoostGraphAlgorithms:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_RenderingOpenVR:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_RenderingOpenXR:STRING=NO \ -DVTK_USE_PCH:BOOL=OFF \ -DVTK_ENABLE_REMOTE_MODULES:BOOL=OFF \ -DVTK_USE_PCH:BOOL=OFF \ -DVTK_MODULE_ENABLE_VTK_RenderingRayTracing:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_RenderingZSpace:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_RenderingMatplotlib:STRING=YES \ -DVTK_MODULE_ENABLE_VTK_fides:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_xdmf3:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_IOOCCT:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_IOUSD:STRING=NO \ -DVTK_MODULE_ENABLE_VTK_IOEnSight:STRING=NO \ -DVTK_ENABLE_CATALYST:BOOL=OFF \ -DPython3_EXECUTABLE=$PYBIN ../ ninja-build # build wheel in dist $PYBIN -m pip install wheel setuptools auditwheel repair dist/*.whl ```

This script was run in a manylinux2014 docker image. You have to use an older version of TBB (as VTK currently does) as the modern one doesn’t support the older toolchain used in manylinux2014.

mwestphal · February 4, 2026, 8:01am

TBH I dont think this was considered specifically, I think you could just try adding VTK_SMP_ENABLE_TBB to the Wheel CI conf and see how it goes.

hakostra · February 4, 2026, 9:52am

I have no exact numbers immediately at hand, but experimented with STDThread/TBB/OpenMP SMP implementations in VTK a while ago. My results did not show big differences between the implementations. More or less in line with the numbers shown here: https://www.kitware.com/vtk-shared-memory-parallelism-tools-2021-updates/

I see the most recent 9.6.0rc3 has the STDThread backend available, but not enabled by default. The two others are unavailable.

If there are no significant performance gains in the OpenMP or TBB backends, I see no reason to have them in the Python wheels. Adding this will add to the total size and you will need to add in and pack the supporting runtime libraries.

mwestphal · February 4, 2026, 10:46am

Very good point @hakostra , I forgot that STDThread is enabled by default, which makes it already available to use.

will.schroeder · February 4, 2026, 11:07am

For simplicity, I would just use std:thread for now.

However, note that anytime the workload of worklets varies significantly, so that load balancing is important, significant performance differences are often realized between TBB and std::thread. I am currently seeing 50-75% speed increases (using TBB vs stdthread) on some Voronoi-based meshing applications.

akaszynski · February 4, 2026, 5:18pm

I’m seeing similar gains (~50%) using TBB vs stdthread for vtkGeometryFilter.

user27182 · February 4, 2026, 6:11pm

I tried adding this here:
https://gitlab.kitware.com/vtk/vtk/-/merge_requests/12884

user27182 · February 4, 2026, 8:52pm

Based on discussion in that MR, enabling TBB by default doesn’t seem like it’s currently viable, and users will need to build from source themselves to use it.

berk.geveci · February 8, 2026, 1:58pm

Sorry for being late to this party and missing that thread (no pun intended!!!). Note that there is a TBB wheel on linux: tbb · PyPI
So it is totally possible to use non-mangle TBB on Linux. There seems to be a TBB wheel that shows up on Homebrew on the mac. Not sure where it comes from.
Using TBB should be possible as long as we are willing to create and maintain TBB wheels for Mac Silicon and Windows. I suggest that we do that.

hakostra · February 8, 2026, 4:51pm

There is no wheel/build for ARM (aarch64), even on Linux. I guess this is a strategic/political choice from Intel, who seems to be the publisher of this package, to only build for x86. I see that as a big disadvantage, as arm is becoming more and more important. If one sets up to maintain repos/libraries/packages for Mac and Windows, one should also do it for ARM.

ben.boeckel · February 9, 2026, 1:58am

That is fine; the tbb wheel should ship the TBB libraries. The question is how other wheels that also want to use TBB’s C++ API should get access to the same libraries as that wheel.