GitLab

Copy all OpenGL interop related configurations from the DAX CMake files

Previously VTK-m would error out on failing to find/setup backends, instead
of clearly stating the issue was finding Boost.

The CMake flag and define differ in their capitalization of the 'm' in
VTKm so I've made CMake variables that match those used in Configure.h.in,
thereby keeping the original naming of VTKm in CMake code, and VTKM in the
C++ code.

This fix also revealed some areas in CellSet and CellSetExplicit where ints
where used instead of vtkm::Ids which caused errors with child classes who
override the methods and returned a vtkm::Id instead of an int.

Also fixed issues that appeared in TestOutOfMemory which got out of date due
to not being compiled since the `VTKM_USE_64BIT_IDS` flag would never be set.
The test now runs and passes when 64bit ids are enabled.

Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't
use the thrust::device_vector, but instead uses thrust::system calls so that
we can support multiple thrust based backends.

Also this has Texture Memory support for input array handles. Some more work
will need to be done to ArrayHandle so that everything works when using an
ArrayHandle inplace with texture memory bindings.

In preparation for supporting base types with more widths, add typedefs
for the base types with explicit widths (number of bits).

Also added a IdComponent type that should be used for indices for
components into tuples and vectors. There now should be no reason to use
"int" inside of VTK-m code (especially for indexing). This change cleans
up many of the int types that were used throughout.

The SystemInformation test always passes. It prints out the contents of
various configuration parameters. The intention is to capture this
information in dashboard reports. That way if a change causes a
dashboard failure and a developer does not have access to the dashboard,
she can look at the output of this test to see the configuration of the
build and that machine.

Although we cannot expect every developer to have pyexpander, for those
that do the build will automatically run it and check the expanded file
in the source code. If they match, a descriptive error is given.

We don't automatically update the file because subtle problems might
occur. It is better to alert a developer to fix the problem properly.