New feature: vtkDataSet::GetPointsDataArray ?

Development
11

Preface: Note that this is with my “software process” hat on and should be seen as a goal; I expect realities to soften some of these things.

I’ve been working to get VTK to follow some stability guidelines. Is VTK-m at a point where it can commit to VTK’s required compatibility guarantees? Things I’d like to see from VTK-m first:

  • a deprecation policy for APIs and that newly-deprecated APIs be kept for a least a release, they continue being tested, etc.
  • lower build machine requirements; requiring 32GB of RAM to comfortably compile is…not great. I did a 4G per-TU ceiling run a while ago, but I think we’d probably need a 1G ceiling run (for non-CUDA builds)
  • release cycles
  • maintained release branches

Things VTK would need to do:

  • support an external VTK-m (distros, HomeBrew, Spack, vcpkg, etc. are really going to want this if we do it since pinning VTK-m to a hash for all consumers too[1])
  • VTK uses only what a given VTK-m release guarantees (so a VTK release (and branch) can only use what is available in a given VTK-m release “group” (read: what distros will generally do patch updates for))
  • Finer-grained VTK::vtkvtkm targets. Right now, using it means vtkm_cont and vtkm_filter; we’d probably want that to be a bit finer-grained to avoid over-linking

[1]vtkm is unmangled symbol-wise, so we can’t mix-and-match VTK-m-as-shipped-by-VTK and other VTK-m usages.