I guess the main problem is that goals of vtk-m seems to be different from ours. We are only interested in running software on commodity multi-core CPU + GPU and prefer a simple solution. It could be less time for us to add a couple of classes to VTK than learning vtk-m’s very generic framework.
If vtk-m could readily fulfill most of our requirements then we could of course reconsider. Our requirements include passing data between filters without copying data to host, rendering filter outputs without copying data to host, easy deployment on a wide range of commodity hardware, have some filters that are important for us - such as surface smoothing and surface to image conversion - implemented on GPU, being able to add new filters without the need to learn a lot about all kinds of architectures that vtk-m supports.