Difference between revisions of "Teleconference 2018-07-11"
(Created page with "Attendees: Policy for granting developer access * What is a non member able to do? ** Can they submit an MR request (but not merge it)? ** That sounds fine for introductory b...") |
|||
Line 18: | Line 18: | ||
* Rendering Topological Entities | * Rendering Topological Entities | ||
* OpenMP | * OpenMP | ||
+ | |||
+ | Ken: working on not requiring a device adapter tag for using a Dispatcher. Will use TryExecute under the covers to find a valid one. Mostly this cleans up the code quite a bit. It increases the use of vtkm::cont::Algorithm quite a bit. Added a way to pass vtkm::cont::ExecutionObjectBase classes to arguments that automatically get converted to the device the algorithm is actually run on. | ||
+ | |||
+ | There are a few instances where a worklet is tied to a specific device because it is holding some device specific structures (usually array portals). Usually this is easily fixed by passing arrays to Invoke with WholeArray* arguments. Sometimes you have to build ExecObject arguments, which is a little more complicated because you have to create dual control/execution objects. The biggest change so far is with particle advection integrators and evaluators, which I am working on right now. |
Revision as of 10:55, 11 July 2018
Attendees:
Policy for granting developer access
- What is a non member able to do?
- Can they submit an MR request (but not merge it)?
- That sounds fine for introductory behavior
- Is the difference that Developers can merge their own MR?
- Should be some vetting process, right?
- Maybe say you can be a developer after some prescribed number of assisted merges (2? 3?)
Apologies for somewhat unstable merges at the end of June.
- ECP milestone deadlines pushed us to accept some merges that we would normally have waited on.
- We should be recovered from any instabilities.
- With that, let's be more vigilant about ECP deadlines.
Upcoming ECP Milestones
- Better Dynamic Types
- Rendering Topological Entities
- OpenMP
Ken: working on not requiring a device adapter tag for using a Dispatcher. Will use TryExecute under the covers to find a valid one. Mostly this cleans up the code quite a bit. It increases the use of vtkm::cont::Algorithm quite a bit. Added a way to pass vtkm::cont::ExecutionObjectBase classes to arguments that automatically get converted to the device the algorithm is actually run on.
There are a few instances where a worklet is tied to a specific device because it is holding some device specific structures (usually array portals). Usually this is easily fixed by passing arrays to Invoke with WholeArray* arguments. Sometimes you have to build ExecObject arguments, which is a little more complicated because you have to create dual control/execution objects. The biggest change so far is with particle advection integrators and evaluators, which I am working on right now.