The `RuntimeDeviceTracker` is a thread-local variable that monitors the
devices to use separately on each thread. This is an important feature
to allow different threads to control different devices.
When a tracker is created on a new thread, it was simply reset, which
makes sense. However, the reset does not take into account the device
selected by `vtkm::cont::Initialize`. This means that if VTK-m was used
in a different thread than it was initialized, it would ignore the
`--vtkm-device` parameter.
To get around this problem, keep track of the `RuntimeDeviceTracker` on
the "main" thread. When a `RuntimeDeviceTracker` is created on a new
thread, it copies the state from that tracker.
It is sometimes the case that you want to copy the state of one
`RuntimeDeviceTracker` to another. This is particularly the case when
creating threads in the control environment. Each thread has its own
copy of `RuntimeDeviceTracker`, so when you spawn a thread you probably
want to copy the state of the tracker from the calling thread.
The previous implementation of `RuntimeDeviceTracker` occasionally
outputted a log at level `Info` about devices being enabled or disabled.
The problem was that the information given was inconsistent (so it would
sometimes announce one change but not announce a different corrective
change). This could cause weird confusions. For example, when you used a
`ColorTable`, it would use a `ScopedRuntimeDeviceTracker` to temporarily
force the device to `Serial`. The log will just tell you that the device
was forced to `Serial` but never tell you that the devices where
restored to include actual parallel devices.
This change helps correct these with the following changes:
* Added a new log level, `DevicesEnabled`, that is a higher level than
`Info`. All logging from `RuntimeDeviceTracker` goes to this log
level.
* Change the logging output of `RuntimeDeviceTracker` to output a list
of currently enabled devices whenever a change happens. That way you
don't have to guess what happend for each change.
* Change `ScopedRuntimeDeviceTracker` to log whenever the scope is
entered or left.
The ScopedRuntimeDeviceTracker now can force, enable, or disable
devices. Additionally the ScopedRuntimeDeviceTracker and the
RuntimeDeviceTracker handle the DeviceAdapterTagAny robustly
across all methods.
As the RuntimeDeviceTracker is a per thread construct we now make
it explicit that you can only get a reference to the per-thread
version and can't copy it.
Fixes#277
DeviceAdapterError existed to make sure that the default device adapter
template was being handled properly. Since the default device adapter doesn't
exist, and nothing is templated over it we can now remove DeviceAdapterError.
The RuntimeDeviceTracker had grown organically to handle multiple
different roles inside VTK-m. Now that we have device tags
that can be passed around at runtime, large portions of
the RuntimeDeviceTracker API aren't needed.
Additionally the RuntimeDeviceTracker had a dependency on knowing
the names of each device, and this wasn't possible
as that information was part of its self. Now we have moved that
information into RuntimeDeviceInformation and have broken
the recursion.
Previously you had to exactly match the case of a device adapter's name to
construct it, which was a source of lots of problems ( OpenMP versus OPENMP, CUDA or Cuda ).
Now `vtkm::cont::make_DeviceAdapterId` and `vtkm::cont::RuntimeDeviceTracker` support
case-insensitive device construction.
The DeepCopy method is used when a ScopedGlobalRuntimeDeviceTracker
is constructed. This in turn causes the rebuilding of the device
names and states which isn't a free operation. Now we copy the already
computed information.
This was noticeable when using ArrayHandleTransform since it uses
ScopedGlobalRuntimeDeviceTracker when construction host side
portals.
Also
- Renamed vtkm::cont::make_DeviceAdapterIdFromName to just overload
make_DeviceAdapterId.
- Refactored CMake logic for unit tests
- Since we're now querying the device tracker for the names, they
cannot be all caps.
- Updated usages of InitLogging to use Initialize instead.
- Added changelog.
VTK-m has been updated to replace old per device worklet testing executables with a device
dependent shared library so that it's able to accept a device adapter
at runtime.
Meanwhile, it updates the testing infrastructure APIs. vtkm::cont::testing::Run
function would call ForceDevice when needed and if users need the device
adapter info at runtime, RunOnDevice function would pass the adapter into the functor.
Optional Parser is bumped from 1.3 to 1.7.
By making RuntimeDeviceInformation class template independent, vtkm is
able to detect
device info at runtime with a runtime specified deviceId. In the past
it's impossible
because the CRTP pattern does not allow function overloading(compiler
would complain
that DeviceAdapterRuntimeDetector does not have Exists() function
defined).
It will reduce the cost of getting the thread runtime device tracker,
and will have a better runtime overhead if user constructs a lot of
short lived threads that use VTK-m.
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.
This allows code to include the RuntimeDeviceTracker without depending
on the device-specific adapters (I think).
Also changed the implementation to use a shared_ptr for the state so you
can pass it around and share the state easier.
