VTK/Supporting Arrays With Arbitrary Memory Layouts: Difference between revisions
| Line 1: | Line 1: | ||
=Background= | =Background= | ||
Not too long ago, the notion of [[VTK/InSituDataStructures|Mapped Arrays]] was introduced in VTK. The main objective behind these was to add support to handle data arrays with arbitrary memory layouts in VTK. This motivation was to support in-situ data processing use-cases without having to ''deep-copy'' arrays from simulation datastructures to VTK's memory layout when the simulation used different memory layout than VTK's. While mapped arrays enabled supporting arbitrary memory layouts in VTK for the the first time, they started to get used by a wider community, a few drawbacks come to light: | Not too long ago, the notion of [[VTK/InSituDataStructures|Mapped Arrays]] was introduced in VTK. The main objective behind these was to add support to handle data arrays with arbitrary memory layouts in VTK. This motivation was to support in-situ data processing use-cases without having to ''deep-copy'' arrays from simulation datastructures to VTK's memory layout when the simulation used different memory layout than VTK's. While mapped arrays enabled supporting arbitrary memory layouts in VTK for the the first time, as they started to get used by a wider community, a few drawbacks come to light: | ||
# Adding a new array layout required developers to implement a large number of pure-virtual methods defined in its superclass hierarchy. This list is discouragingly large especially for simulation developers, not too familiar with VTK. For veteran VTK developers, this was tedious at the least. | # Adding a new array layout required developers to implement a large number of pure-virtual methods defined in its superclass hierarchy. This list is discouragingly large especially for simulation developers, not too familiar with VTK. For veteran VTK developers, this was tedious at the least. | ||
Revision as of 17:43, 7 July 2015
Background
Not too long ago, the notion of Mapped Arrays was introduced in VTK. The main objective behind these was to add support to handle data arrays with arbitrary memory layouts in VTK. This motivation was to support in-situ data processing use-cases without having to deep-copy arrays from simulation datastructures to VTK's memory layout when the simulation used different memory layout than VTK's. While mapped arrays enabled supporting arbitrary memory layouts in VTK for the the first time, as they started to get used by a wider community, a few drawbacks come to light:
- Adding a new array layout required developers to implement a large number of pure-virtual methods defined in its superclass hierarchy. This list is discouragingly large especially for simulation developers, not too familiar with VTK. For veteran VTK developers, this was tedious at the least.
- Virtual API for accessing values in a generic way meant that the access was invariably slow and kept compilers from performing further optimizations.
This new design addresses both these issues.
Caveats
This design targets vtkDataArray and subclasses alone. vtkDataArray, in VTK. Hence, this discussion is not applicable for certain vtkAbstractArray subclasses that are not vtkDataArray subclasses as well e.g. vtkStringArray, vtkVariantArray. Since such arrays are rarely, if ever encountered in in-situ use-cases, this should not be an issue.
Classes
vtkGenericDataArray is a new subclass of vtkDataArray that does all the the heavy lifting to implement the pure-virtual API expected by vtkAbstractArray and vtkDataArray and defines a new concept that the subclasses should implement. All methods expected to be implemented by the subclasses are non-virtual and hence provide for fast access and compile time optimizations.
vtkSoADataArrayTemplate, and vtkAoSDataArrayTemplate are concrete subclasses templated over ScalarTypeT. SoA stands for Structure of Arrays, while AoS stands for Array of Structures (the traditional VTK array memory layout).
