From XVis
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Book title: Achieving Portable Performance For Visualization, Using VTK-m

The book is organized into three parts:

  1. Concepts in Portable Performance and Modern Architectures
  2. The VTK-m Approach
  3. In Practice

Each chapter has dependencies listed. A dependency for chapter C1 on chapter C2 means that C2 should be complete (or in reasonable shape) before C1 is started, so that the terminology can be consistent.

Introduction Chapter

Chapter 0: Introduction

  • The Organization of this Book
  • The scope of the VTK-m: what it does, why it is useful

Dependencies: last chapter written (or at least all other chapters should be taking shape)

Authors: Hank and Ken

Part 1: Concepts in Portable Performance and Modern Architectures

Chapter 1.1: Revolutions in Processor Architectures


  • threading vs vector / multi-core/many-core / host-device / memory hierarchies
  • historical discussion: Moore’s law, but Dinar scaling failed … how to deal with extra transistor
  • exascale power story, state of current Top500

Dependencies: none

Chapter 1.2: GPU

Dependencies: Chapter 1.1

Experts: Tom Fogal, NVIDIA?

Chapter 1.3: Xeon Phi

Dependencies: Chapter 1.1

Experts: James Reinders of Intel said he would participate

Chapter 1.4: Programming Many-Core Architectures

Topics: CUDA, TBB, OpenMP, OpenCL, OpenACC Dependencies: 1.1? 1.2 and 1.3?

Chapter 1.5: Functor Based Programming


  • function with no side effects can be applied in parallel to your heart’s content
  • Kernels similar to functor based programming

Dependencies: None?

Chapter 1.6: Data-Parallel Primitives

Dependencies: None?

Chapter 1.7: Thrust

Dependencies: None?

Ken: I know we discussed that Thrust was different than DPP, but we might consider putting Thrust and other DPP implementations (TBB, CUDPP) as a subsection of that chapter.

Chapter 1.8: Higher-Levels Patterns on Top of Data-Parallel Primitives

  • index-reversal, topology reconstruction, stream compaction
  • See Ken's SC Frontiers paper for more details on these patterns
  • Check around with VTK-m group to see if there are more.

Dependencies: 1.6

Chapter 1.9: A Data Model for Representing Scientific Data

Expert: Jeremy Meredith, Dave Pugmire Student: James Kress (at ORNL in Fall)

Dependencies: None?

Chapter 1.N: Generic Programming

Templates, fancy templates, generic programming, tags

Part 2: The VTK-m Approach

Chapter 2.0: How to compile VTK-m.

  • Download, CMake, dependencies (Boost, etc)

Dependencies: None?

Chapter 2.1: Basic VTK-m Usage

Five important subsections:

  1. Memory Management (Array Handles)
  2. VTK-m’s Data Model
  3. Device Adapters (introduce topic: abstract model, supported devices, we’ll talk more about it later)
  4. Filters
  5. Example Programs

(This may take several students working)

Dependencies: None?

Chapter 2.2: Developing Algorithms in VTK-m

Three important subsections:

  1. Worklets and different worklet types, signatures
  2. Dispatchers
  3. Getting data from control to execution environment (harkens back to host-device)

Dependencies: 2.1?

Chapter 2.3: Device Adapters

  • how device adapters work
  • list of things in a device adapter: (1) how to move between host and device and (2) collection of algorithms that are implemented.
  • must do a scheduler/map, other DPP derived from it. But often done over again for efficiency in a specific language
  • how to write your own. (this question may frame some of the points above)

Dependencies: 2.1 (or maybe 2.1 should distill a section from this?)

Chapter 2.4: Algorithms that Use Device Adapters Directly (no worklets)

Dependencies: 2.1, 2.2, and 2.3?

Chapter 2.5: Worklets

  • how they work
  • how to create a new type

Dependencies: 2.1?

Chapter 2.6: Explore One Algorithm (Contour) In Depth

Question of how far to go. Hank likes slides from CS, JM that should step-by-step (should there be more chapters like this? If so, should this become its own part of the book?)

Dependencies: 2.1?

Chapter 2.7: Here’s how VTK-m fits

  • in situ, post-processing
  • No MPI … you add it
  • VisIt/ParaView

Dependencies: none?

Chapter 2.X: Array Handles

Where does this go?

Chapter 2.Y: VTK-m data model

Part 3: In Practice

Chapter 3.1: search data structures

Dependencies: 1.6?

Chapter 3.2: the case for performance

talk about why we believe this approach will provide portable performance, and success stories (this would be XVis people, not UO students ... except for Matt Larsen)

Dependencies: None?

Chapter 3.X: more in practice stories?

would people want to submit a few in practice success stories (this would be Xvis people, not UO students)

Dependencies: None?

UO Students

The following UO students will be involved:

  • Roba Binyahib (HPC Visualization)
  • Ryan Bleile (Computational Science, GPU, Vis, esp. advection)
  • Vincent Chen (incoming student, worked with Berk on SMP+VTK over summer)
  • Daniel Ellsworth (HPC, Education)
  • James Kress (HPC Visualization, at ORNL with Jeremy Meredith and Dave Pugmire in Fall, some EAVL code contributions)
  • Stephanie Labasan (HPC, Vis, Power)
  • Matt Larsen (HPC Visualization, extensive EAVL experience)
  • Samuel Li (HPC Visualization, some EAVL experience)
  • Brent Lessley (VTK-m experience with Rob Maynard)
  • Sudhansu Sane
  • Chad Wood (HPC)
  • Hang Xu (incoming student, has taken HPC class, will be taking Vis class concurrently)