GitLab

Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.

Previously TransferToOpenGL would rely on every array handle implementing
the CopyInto method for transferring to work properly. This was problematic
as most Implicit arrays don't implement CopyInto.

Now we use the Devices built in Copy infrastructure to facilitate moving
data from an implicit array to concrete memory which we can be passed
to OpenGL. As an additional optimization, the temporary memory for this
interop is cached in the bufferstate.

Change the OpenGL configuration to require GLEW as most of the OpenGL
code actually requires GLEW (or will as soon as the VBO branch gets
merged in).

Also removed some stray find_package commands and rearranged the
configuration to use the vtkm_configure_component_* commands instead.

There were a couple of places where the configure scripts did not add
either includes to VTKm_INCLUDE_DIRS or libraries to VTKm_LIBRARIES.

The biggest offender was when the examples used find_package to load the
VTK-m configuration it needed. find_package cleared out the includes and
libraries, but it did not clear out the VTKm_<COMPONENT>_FOUND
variables. Normally, these variables would not be set before
find_package is called, but in this case the examples were called after
some partial configuration. I got around this issue by clearing out all
the *_FOUND variables in VTKmConfig.cmake.

Make everything consistent with new builds.

To clarify what functionality the classes inside provide.

Previously they had been comitted with Windows line endings.

Copy the OpenGL Interop code from DAX and convert it to VTKm.
Tests include transferring data to an OpenGL context for all VTKm common
data types.

A WindowBase class using GLUT is also included.

This is used with the FunctionInterface::DynamicTransformCont method to
convert a call of arguments using dynamic array handles to a function
templated on concrete types.

We now can verify that the array handle is usable by a device adapter.

This includes the configure scripts to setup if you want a 32bit or
64bit build.