Dev telecon log Feb 29 2016

Attendees

  • Eric Brugger
  • Cyrus Harrison
  • Allen Sanderson
  • Kathleen Biagas
  • Hank Childs
  • Mark Miller
  • Dave Pugmire
  • Matt Larsen
  • Kevin Griffin

Repo

We are the last big repo at NERSC. One option was to host repo at IL. Another option is to move to Git sooner.

Proposals:

  • switch to IL now.
  • start prepping for Git transition, and stick at NERSC. If emergency, then switch to IL.

How to make sure we make a timely transition to Git

From Last Meeting

  • repo at NERSC is going away. What to do?
    • Intelligent Light offers an option
    • Move to Git sooner?
      • Current NERSC status allows a significant window of time to decide, maybe as much as a year
      • We're swimming in the pool without a lifegaurd
    • We need to have actual planning on transition to Git
      • Who will plan this and who will do the work
    • Plan is to stay at NERSC and start planning transition to Git by Jan 1, 2017
      • If worst happens can transition to ILight as a backup
    • Git Transition Working Group
      • Cyrus, Hank, Burlen might be good to volunteer
    • Clearcase transition as example
      • Hank says we 'lost a lot'
      • Might be able to do better job preserving history. But, maybe expedience will trump a lot of that too
      • Script did first 1,500 checkouts at weekly intervals over Clearcase history

We need to make concrete plans.

Proposal: spin up working group with interested parties

Working Group

  • Cyrus
  • Hank
  • Burlen & Hari not on call, but we think both would be good

Compilers

Hank reports back that investigation of varying compilers/flags hasn't made a big difference yet, but they are still trying.

New GL in VTK

  • VTK7 has an OpenGL 3.2 backend
  • We will need to rewrite our rendering code
    • we should search current VTK modules and see if they fit our needs now
  • KitWare and NVidia changes in GL
  • We have custom opengl code in our plots (volume, streamline, spreadsheet)
    • Most VisIt mapper modules rely on avtMapper which ultimately uses VTK modules and setting flags in VTK modules to do the rendering
    • In some cases (volume, streamline, spreadsheet) that have actual opengl calls in them.
      • Some GL state initialization that is being handled by VTK
    • Instead of re-vamp/re-work custom stuff, see if VTK stuff will fit our needs for those plots now. May be able to abandon our custom stuff.
    • Polydata mapper may be completely gone
    • Fixed function from fully programmable interface
    • Is answer same/different between VTK-6 or VTK-7
      • KitWare advises 7 or 7.1
      • Implies makes no sense to do all this porting on 6 series
      • Kathleen tried 6.3 with old OpenGL backend and ran into text rendering issues. Then tried OpenGL 2 backend and that was just not possible.
      • Burlen and Tom havie taken Kathleen's 6.3 branch and moved into Github to work on it.
    • Can do some useful work with 7 in preparation for 7.1 even if a lot of bugs there
  • Offscreen with mesa/gcc will be very bad performance
    • This was revealed in a recent meeting with Kitware, Sandia and LANL
    • Will need llvm pipes, egl, open-swer, ?? to address performance
    • Os-mesa has a llvm-pipe backend. So isn't this just a re-compile? llvm-pipes has to be present during the build
    • Can we use system llvm? Cyrus thinks best not to.
    • Spack builds llvm
    • VTK-7 won't even run without OpenGl 2.0 os-mesa
  • What about using VTK-m for rendering?
    • Might even be more work than VTK-7/OSMesa/llvm
    • Matt has a rasterizer but it won't run shaders. And, its still prototype code that needs serious work.
    • Have 20 plots so far
    • VTK-m might have mesa anyways. They are looking at this.
    • In terms of effort, Burlen believes llvm/pipes is significantly less effort
  • Burlen/Tom have started looking at integrating VisIt with VTK-7
    • Will need to re-write opengl infrastructure
  • Brad did some effort to re-purpose to newest VTK, what happened to that?
    • Way VTK classically used opengl was a non-optimal pattern (open, vert, vert, close)
    • Did some work to make work with new GL and rendering infrastructure
  • If looking into the future, is Vulkan a consideration? VTK is OpenGL 3.2. What version is OpenGL at? 4.5.