update to support new vtk-m #229
Conversation
|
@cyrush Let me know if you see any issues with this RC of vtkm and I can help work out any issues. Once this is in I will get the versions of VTKm and VTKh in visit updated. |
|
@jameskress -- yes starting to take a look at issues now. I'll ping for help after some digging. |
|
@cyrush Great! I just built VisIt with the VTK-m RC and this branch of VTK-h. I had to remove an include from vtkh.cpp, but other than that it build and seemed to run correctly. |
|
@jameskress -- is this the header issue you saw (missing |
|
@cyrush No, my issue was that I had to remove "#include <vtkm/cont/DeviceAdapterListTag.h>" from vtkh.cpp. It was bringing in deprecated stuff, and seems fine without it being there. I have however seen your issue quite often. I fix it by modifying the include path in the vtkm header file "vtkm/cont/internal/OptionParser.h". I am not a cmake wizard, so have always assumed that the path could be fixed by giving the cmake files more "smarts", but I could be wrong. We may need to actually do an MR with vtkm and have the header path permanently changed. Any ideas on if CMake can do this for us, or does vtkm need to change? This is the change I usually do: // Include from third party. // Now restore the header guards as before so that other includes of (possibly different versions |
|
thanks @jameskress -- it does seem like vtk-m should be changed to use a path consistent with their install. I'll try a patch and see how that goes. |
|
Made some progress (compiling and linking!), but now all of my unit tests are segfaulting. I had to do something different with fpic, however not sure that would cause such a drastic change. |
|
@cyrush I can confirm the seg faults as well. For me there was an issue with vtkh not knowing the path at runtime to the vtkm lib dir, but after exporting that I got the seg faults. I am a bit lost also as to what has changed so much that this is happening. May have something to do with that deprecated header, as that is the most substantive change. I'll look into that and see if I can find anything else. |
|
thanks @jameskress I will be able to look at this again on Friday. The |
|
@cyrush No worries! I will see if I can find out more today. So far I have the smoke test passing but test 5 (dataset) is failing in a getglobalbounds call. Plus most of the others are also failing, aside from threshold and the parallel smoke test. Update: I did a fresh checkout and install of this branch and the RC branch from vtkm. Now all of the tests are pasing except for 4 (t_vtk-h_empty_data, t_vtk-h_iso_volume, t_vtk-h_marching_cubes, t_vtk-h_point_renderer) I don't know what was different between the two checkouts, but these 4 seem to be failing due to the same assertion: |
|
@cyrush With the fresh checkouts and builds plus the camera fix that Ken has done, all of my unit tests are now passing. |
|
@jameskress Q: were you doing static libs or shared libs for VTK-h? |
|
For me, using OpenMP with threads greater than 1, yields a seg fault. Looking at the most basic test (our vtk-m smoke test): vtk-m smoke testdefault omp threadsOMP_NUM_THREADS=1OMP_NUM_THREADS=8Looking all of the vtk-h tests:OMP_NUM_THREADS=1 (OK)OMP_NUM_THREADS=2 (most tests fail) |
@cyrush I have been building with shared libs. It has been a while also since I have been able to use openmp due to downstream codes I have been working with. Compiling with openmp and static libs gives me what appear to be SOME of the same problems you are seeing. I am able to get test 5 to pass just fine, but most other tests after that failed The following tests FAILED: |
|
@goodbadwolf This is the branch we are using to update, so if you can get the changes here (let me know if you need perms, etc) that will make it easiest to check them |
VTK-m introduced new APIs to batch text and line annotation rendering. This speeds up the rendering of the annotations, but requires calling: - `Canvas::BeginTextRenderingBatch()` and `Canvas::EndTextRenderingBatch()` for batched text rendering. - `WorldAnnotator::BeginLineRenderingBatch()` and `WorldAnnotator::EndLineRenderingBatch()` for batched line rendering
@cyrush It took me longer to get a working build of vtk-h than expected. I have the changes that should fix the issue, but I do not have the perms to push it to this branch. Preview of the fix: |
|
@goodbadwolf -- thanks for the update! You should have permissions now, so try to push and let me know if there are problems. |
|
@cyrush - Done |
|
thanks @goodbadwolf -- I tested in ascent and things look good! |
api changes for new vtk-m
majority of work done by jameskress