User:Tfogal

NOTE a lot of the IceT and HW accel rendering stuff on this page is out of date; I'll fix it eventually.

Me

I'm at SCI, I hack VisIt, and I'm doing a Masters as related to parallel volume rendering. I frequent the visit-developers mailing list, so you can get my attention by posting there. Enough about me...

IceT Status

This is just a temporary portion of my user page, so Sean knows (.. and I remember) what the state of IceT-based rendering in VisIt is.

The most important considerations are already written in IceT Development Concerns. You might also want to look at the page intended to be user documentation: Using the IceT Parallel Compositor. As one sentence summaries: (devel) We need to reorganize SR so that renderers assume images are in the framebuffers, not passed as arguments, and (user) A user must build against Mesa for everything to work out. The symptom of building against the wrong GL library is blank (white) images at run time.

HW Rendering

Hardware rendering with IceT does not work. The issue is in choosing an OpenGL library; IceT uses the OpenGL implementation it was linked to at compile time; there is no support to choose the implementation at run time. Therefore in our HW-rendering jobs, where there are a mix of both HW and SW based renderers, only one `set' of those can be made to work. It should be noted that VisIt/VTK can be made to work because they use a factory-style OpenGL initialization under the hood; we setup the appropriate configuration in InitVTK which is called from VisItDisplay subclasses.

Implemented 'Solution'

Arguably the best solution is to write an "OpenGL" library, which is really just a set of function pointers. Clients would be required to call an initialization routine before using any OpenGL functions, and the initialization routine could set all of the function pointers from the appropriate OpenGL implementation (system or Mesa).

With this solution, IceT links against our faux OpenGL library, not knowing the difference. Then the VisIt engine links against both IceT and the faux OpenGL library. VisIt would then be required to call faux-OpenGL's initialization routine before it calls any IceT functions. IceT would then use the correct OpenGL implementation without even knowing it -- no changes to IceT required. It's essentially the LD_PRELOAD game, except we're doing it during runtime instead of at load time.

This is exactly what we've done; see Parallel OpenGL for details.

That said, this still doesn't work on the trunk. We use GLEW as the faux OpenGL library, and since IceT is built earlier, it's linking against whatever OpenGL we give it then (currently, build_visit forces Mesa). We need to make IceT builtin to VisIt, so that it can link against VisIt's in-tree GLEW.

IceT General Issues

First, see the known issues section in Using the IceT Parallel Compositor.

Sorting

IceT needs to be told the correct composition order. This is a bit harder than one might think, because we don't necessarily *have* a valid compositing order. In some cases we do, in some cases if we did a sort-first decomposition we could get one, and in some other cases we just punt and render all transparent geometry on processor 0.

For 1.12, as per conversations on VisIt developers, I added code to detect transparency and punt back to using the old network manager. This avoids the issue, at a cost of performance.

Pages Under Development

I'm working on these pages, and don't quite consider them ready for `prime time' yet, so they're only accessible from here. When I feel they are complete, I'll move them to the appropriate index so that casual readers could potentially find them.

ToDo

Very frequently, I'm reading through code or the mailing list or what-have-you, and start to think, `wow, it would be really great if we ...'. Then I realize I'll essentially never have time for it, and so I put it here so it at least gets documented. Who knows, maybe I'll get lucky and finally find time to do these someday ...

Other than the grouping I've imposed, these are essentially unordered.

Tests

  • SR: we need a test to cover the zoomed in case of a volume plot. in particular, it should hit the case where process 0 has data, and some but not all other processes have data.
  • itaps.py: test should detect VisIt was not built with itaps and return an `UNSUPPORTED' result.
    • Mark notes that there is a 'visit_plugin' which is probably the proper location to implement the 'is this database built?' logic. Currently visit_plugin only knows about private plugins, so it would need to be extended to know about all plugins.
  • visus.py: test should detect VisIt was not built with visus and return an `UNSUPPORTED' result.
  • scalable.py: test should be skipped or somehow `do the right thing' if the test script is only told to run in serial mode.
  • State Objects: we need some tests to ensure state objects are updated/consistent. In particular, there is no coverage of the java bindings as of now.
  • QueryNoise: I forget which test, but the one which generates a 'QueryNoise' file is generating different results on different hosts. Mark suggests that this could be an issue of using a random number generator in the test, so perhaps there's a simple fix.
  • runtest: Many lines are > 80 characters, including lines which are output to the terminal/user.
  • runtest: Instead of conditionally invoking VisIt, we should conditionally build environment and argument strings, and then have one line which invokes VisIt at the end. As is, one must currently modify 5 or 6 lines to add a new command line argument.

Source

  • POD: The POD documentation in internallauncher seems to be misconfigured somehow; perldoc doesn't quite grok it correctly.
  • AMR GC problems: Hank fixed these with tcmalloc, but it might be nice to avoid that dependence. The issue appears to be related to VTK's garbage collection. It turns out vtkObjectBase has a FastDelete method which decrements the reference count but does not perform garbage collection (with the caveat that you cause a leak if you use it on an object that should be collected!). We should look into whether or not that > 1 reference count guarantee applies to us, and if that can solve our problem without an external dependency.
  • compiz/Qt: VisIt doesn't play with Compiz; looks like there is some sort of issue with how Qt interacts with X when Compiz is enabled. When we finish the upgrade to Qt4, we should examine this and make sure VisIt works with Compiz.
  • signals: signalhandler_core uses the same debug streams we normally use to output debug information. This is not safe; a signal handler may not utilize a stream which may have been in use when the handler was invoked.
  • signals: signalhandler_core should not abort, but re-raise the signal (after clearing the signal handler function, of course -- which it already does). This is useful in debugging.
  • Engine: The Engine's destructor is only called if the developer defines an obscure debugging flag which is not set by default. It is probably ifdef'd out because bad things (tm) happen if we call it (IIRC VisIt crashed on exit). We should always call that destructor; whatever bug it uncovers should be addressed directly.
  • visit: sub-options to debugging tools. The front end launching script (i.e. visit) parses arguments before they get passed to internallauncher. However the front end launcher has only basic knowledge of debugging tools, such as valgrind. In internallauncher, the valgrind arguments are parsed as a series until we see a component name; e.g.:
 -valgrind -a -b -c -d engine_par

Means we should run the parallel engine under valgrind, passing the options -a -b -c -d to valgrind. However, the front end launcher has no notion that -a -b -c -d are sub-options, only applicable to valgrind, and parses them like VisIt options! This means that if valgrind and visit have any intersection in command line options used, and the user utilizes one of those, we strip out all valgrind options following the dual-interpreted option! As an example, visit parses:

 -valgrind --tool=memcheck -v --leak-check=full engine_par

to mean 'run engine_par under valgrind with the options --tool=memcheck'. The -v is thought to be the VisIt option for version specification, and everything after it is stripped.

I should note that valgrind is the situation where I found this, but this is applicable to all of our wrapper-launchers (e.g. -debug-malloc, probably -gdb, etc.).

  • internallauncher: There is no notion of a 'launch option' as opposed to a 'launch method'; this makes implementing things like launching under valgrind awkward, as valgrind must become it's own launch method. Therefore it must make assumptions about how to launch VisIt.
  • warning patrol: warnings are all over the place. The old-style streams library will be the worst to fix, because some of that is embedded in VTK headers.
  • GGCM database: Does the GGCM DB correctly setup all the info needed for time sliders? Test/verify, and fix if not.
  • src/test: Does the '-cycleregex' option give correct file grouping behavior? It should both extract timecodes and group filenames correctly if the regex is good.
  • gui: There needs to be a way to select multiple files for a given database: e.g. data file and grid file.
  • src: enable-viewer-mesa-stub should be reworded such that the help string is more clear.
  • audit: The IceT renderer returns a 4-component (GL_RGBA) image instead of a 3-component (GL_RGB) image. Parts of VisIt assume 3-components from an avtImage, which usually makes sense because avtImageRepresentation::NewImage returns a 3-component image. This has been fixed in one place, but we're unlikely to get it right until we audit every method which tries to 'GetScalarPointer' on the vtkImageData within an avtImage. Bleh.
  • SocketConnection.C: NeedsRead() should throw an exception if the select() call gives any sort of error.
  • audit: There should be a full audit done for system call interruption problems. That is, code should either explicitly handle restarting the system call, or have a comment which notes why we wouldn't want to restart the system call.
  • audit: shell scripts in svn_bin should be usable by a strict POSIX shell, such as dash, maybe bash --posix is good enough.
  • doc: '-cycleregex' is basically undocumented: it is only mentioned in '-fullhelp' output.

Version Control

  • hooks: changes to certain RO objects should trigger an email to the committing user.
  • hooks: state_update.sh should detect when a user is committing both an XML and its corresponding autogenerated file (within reason), and refrain from warning if the user is submitting all required files.

Build System

  • build_visit: HDF4 might have an issue with szip; I've witnessed a case where the configuration failed and config.log said checking the size of int * failed because it couldn't link against libsz.so (which is szip). Removing the --with-szip option fixes this...
  • build_visit: The BoxLib build runs once in 3D, installs, and then cleans, installs a patch to convert to 2D, and builds + installs again for the 2D version. This really screws things up if you rm -fr visit/boxlib without removing CCSEApps, because a second run of BoxLib will only build the 2D version of the library!
  • difficulty: VisIt is too hard to build. I think integrating Mesa into the build system will do wonders for this. This will necessitate VTK too, which is also a gargantuan pain to build.
  • build_visit: use silo's --with-Qt-dir instead of --with-Qt-bin, --with-Qt-lib, etc. The latter options don't appear to work right with Silo-4.6.1. --with-Qt-dir=${VISITDIR}/qt/${QT_VERSION}/${VISITARCH} appears to work.
  • build_visit: In some cases, Qt chooses to not build a 'libqt-mt.so' file, even if configured with -thread. This appears to be the case when the user's OpenGL library is determined to be multithreaded (linked with pthread): in this case, Qt forces libqt.so to be threaded, despite the name! In such a case, we need to symlink libqt.so to libqt-mt.so, because the silo build assumes libqt-mt.so will exist.
  • build_visit: silo brings forth a libtool bug on x86_64. First, libtool screws things up such that libraries in /usr/lib are searched to satisfy dependencies, and /usr/lib64 is not searched at all! If the user hacks in /usr/lib64 to LDFLAGS, libtool's 'smart parsing' ideas removes the added -L option. There is a workaround completely commenting out the existing configure line in build_visit and replacing it with:
 WITH_QT="--with-Qt-dir=${VISITDIR}/qt/${QT_VERSION}/${VISITARCH}"
 ./configure                                          \
   --prefix="$VISITDIR/silo/$SILO_VERSIO}/$VISITARCH" \
   "${WITH_QT}"                                       \
   --disable-silex --disable-fortran --with-gnu-ld    \
   --with-pic

The WITH_QT part is actually because of the first build_visit issue.

  • build_visit: Some sort of mirror system for finding tarballs would be nice. As is, all the tarballs are hardcoded in, and there is a distinction drawn between 'internal' (hosted at LLNL) and 'external' files.