Difference between revisions of "Teleconference 2018-03-21"
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | Attendees: | + | Attendees: Ken Moreland (SNL), Matt Larsen (LLNL), Tom Otahal (SNL), Rob Maynard (Kitware), Utkarsh Ayachit (Kitware), Berk Geveci (Kitware), Allie Vacanti (Kitware), Ollie Lo (LANL) |
| + | |||
| + | Matt has been doing some small comparisons of VTK-m algorithms with VisIt. Also integrating some vis with Physics code. | ||
| + | |||
| + | Space is reserved for code sprint the week of August 28. | ||
| + | |||
| + | There has been some issues with VTK-m on CUDA with IBM systems. | ||
| + | |||
| + | Rob has been working on color tables. Can now build a lookup sample table. This makes it visually indistinguishable from how ParaView behaves. | ||
| + | |||
| + | Rob has been pulling some performance numbers for GTC. Going to talk about multiblock and use of multi streams. Going to talk about unified memory. | ||
| + | |||
| + | Allie has been running performance for new OpenMP device. So far, performance much worse than TBB. | ||
| + | |||
| + | Utkarsh has checked in new filter interface and other multiblock support. | ||
New filter interface: | New filter interface: | ||
* change default to select all fields to map from input to output | * change default to select all fields to map from input to output | ||
| + | ** No one argues we should not do that. '''Make that change.''' | ||
* do we need to rethink memory management for CUDA? | * do we need to rethink memory management for CUDA? | ||
** after mapping a field, show we unload both from the CUDA device (i.e. call ReleaseResourcesExecution)? | ** after mapping a field, show we unload both from the CUDA device (i.e. call ReleaseResourcesExecution)? | ||
| + | ** '''Yes, we should at the very least unload the input data''' | ||
| + | ** Rather than move memory to device move device to memory? | ||
| + | ** Open a bug. | ||
* not much point having coordinate systems in separate space, move back to fields? | * not much point having coordinate systems in separate space, move back to fields? | ||
| + | ** There may still reason to keep them separate to support fast paths in the virtual coordinate systems | ||
| + | ** We might want to table this until we have gone further down the virtual array handles. | ||
* Should FieldSelection have a mode where you except all fields except those specified? | * Should FieldSelection have a mode where you except all fields except those specified? | ||
** Use case: if thresholding by a mask, no sense in copying that field from input to output | ** Use case: if thresholding by a mask, no sense in copying that field from input to output | ||
| + | ** '''Yup''' | ||
| + | * Update interface to dot/cross product filter | ||
| + | ** Alias "primary" filter | ||
| + | ** Support coordinate systems | ||
| + | |||
| + | Are a lot of people going to be in GTC next week? | ||
| + | * Probably skip it | ||
Latest revision as of 13:49, 21 March 2018
Attendees: Ken Moreland (SNL), Matt Larsen (LLNL), Tom Otahal (SNL), Rob Maynard (Kitware), Utkarsh Ayachit (Kitware), Berk Geveci (Kitware), Allie Vacanti (Kitware), Ollie Lo (LANL)
Matt has been doing some small comparisons of VTK-m algorithms with VisIt. Also integrating some vis with Physics code.
Space is reserved for code sprint the week of August 28.
There has been some issues with VTK-m on CUDA with IBM systems.
Rob has been working on color tables. Can now build a lookup sample table. This makes it visually indistinguishable from how ParaView behaves.
Rob has been pulling some performance numbers for GTC. Going to talk about multiblock and use of multi streams. Going to talk about unified memory.
Allie has been running performance for new OpenMP device. So far, performance much worse than TBB.
Utkarsh has checked in new filter interface and other multiblock support.
New filter interface:
- change default to select all fields to map from input to output
- No one argues we should not do that. Make that change.
- do we need to rethink memory management for CUDA?
- after mapping a field, show we unload both from the CUDA device (i.e. call ReleaseResourcesExecution)?
- Yes, we should at the very least unload the input data
- Rather than move memory to device move device to memory?
- Open a bug.
- not much point having coordinate systems in separate space, move back to fields?
- There may still reason to keep them separate to support fast paths in the virtual coordinate systems
- We might want to table this until we have gone further down the virtual array handles.
- Should FieldSelection have a mode where you except all fields except those specified?
- Use case: if thresholding by a mask, no sense in copying that field from input to output
- Yup
- Update interface to dot/cross product filter
- Alias "primary" filter
- Support coordinate systems
Are a lot of people going to be in GTC next week?
- Probably skip it
