Dev telecon log Feb 29 2016
- Eric Brugger
- Cyrus Harrison
- Allen Sanderson
- Kathleen Biagas
- Hank Childs
- Mark Miller
- Dave Pugmire
- Matt Larsen
- Kevin Griffin
We are the last big repo at NERSC. One option was to host repo at IL. Another option is to move to Git sooner.
- 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
- Burlen & Hari not on call, but we think both would be good
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.