Difference between revisions of "HanProgressReportSep08"

From Immersive Visualization Lab Wiki
Jump to: navigation, search
(TODO)
 
Line 48: Line 48:
 
     * future work
 
     * future work
 
     * conclusion
 
     * conclusion
 +
 +
 +
=== DONE ===
 +
* synchronization
 +
    * sync with rendering and video frequency (24 fps)
 +
    * when rendering is slow, skip frames
 +
    * when rendering is fast, redraw frames
 +
 +
* performance optimization
 +
    * fixed memory management
 +
    * OpenGL PBO does not allocate data immediately and try to allocate data when write operations are issued.
 +
    * the result was, whenever new data is loaded, memory allocation process ran, which slowed the whole system significantly.
 +
    * minimized the memory foot print so that the memory block can be used over and over again.
 +
    * what we lose is the caching mechanism but it is not a big issue in video playing
 +
 +
* performance optimization II
 +
    * added prefetching
 +
    * the mesh geometry of the current frame passed to the next frame and load data for the next frame
 +
    * it is useful when the plane is not moving
 +
    * another big advantage is, thanks to PBO's asynchronous I/O mechanism, we can parallelize memory copy and rendering process.
 +
   
 +
* performance optimization III
 +
    * aggregate block I/O request
 +
    * found out random access reads across multiple files are slower than reading files one by one.
 +
    * we sort bricks by each brick's file name, so access to one file can take place all together.
 +
 +
* performance optimization IV
 +
    * RGB format without shader
 +
    * we used to use shader programs to combine channel data.
 +
    * we give up the control of each channel, however, we get more performance
 +
    * RGB format is usually an optimized format in OpenGL
 +
 +
* multiple players
 +
    * removed all the global variables so that multiple instances of rendering class can co-exist.
 +
    * created two Geode class and they run successfully in covise
 +
    * MultiVirvoNode.[cpp|h]
 +
 +
* plugin improvement
 +
    * added an menu item so the plugin can hold loading all the data when initializing and start loading when users request
 +
    * added pixelToVoxel ratio and brickLimit control

Latest revision as of 15:48, 16 September 2008

UP

TODO

  • PRELOADING
   - preload data: load as much data as possible before starting playing, to fully utilize memory cache.
   - make sure to correctly count the number of bricks that is being loaded at each frame
   - load up to level 2 from level 5
   - make sure the eviction takes place on old frames
  • PLUGIN
   - change plugin so that initialization step takes place when "load data" is selected. Now it loads everything when opencover starts
  • THINKABOUT
   - revert to memory pool instead of pixel buffer object pool..
   - * re-add prefetching thread
   - * implement budget based algorithm
  • PERFORMANCE
   * measuring performance for the following step
     - LOADING, preload miss
     - # bricks loaded
     - # brick upper bound
     - meshing generation
     - rendering
     - with preloaded data: 40~50 fps, 0.025 ~ 0.02 sec/frame
     - without preloading: around 10 fps, 0.1 sec/frame....:(
   * prefetching next frames
   * point of interest (check paper again)


  • multi-volume support
   * mesh generation - generating a mesh for multivolumes under one constraint - memory size
   * rendering - multi-volume rendering
         o new rendering algorithm: need to manage multi bricks overlaps with several bricks! 
   * time-series multivolume rendering - need to handle multi timesteps
  • WRITEUP
   * contribution, introduction
   * related work
     - mipmap
     - large scale data management
     - ?
   * system architecture
     - 
   * result/performance
     - introduction of CAVE
   * future work
   * conclusion


DONE

  • synchronization
   * sync with rendering and video frequency (24 fps)
   * when rendering is slow, skip frames
   * when rendering is fast, redraw frames
  • performance optimization
   * fixed memory management
   * OpenGL PBO does not allocate data immediately and try to allocate data when write operations are issued.
   * the result was, whenever new data is loaded, memory allocation process ran, which slowed the whole system significantly.
   * minimized the memory foot print so that the memory block can be used over and over again.
   * what we lose is the caching mechanism but it is not a big issue in video playing
  • performance optimization II
   * added prefetching
   * the mesh geometry of the current frame passed to the next frame and load data for the next frame
   * it is useful when the plane is not moving
   * another big advantage is, thanks to PBO's asynchronous I/O mechanism, we can parallelize memory copy and rendering process.
   
  • performance optimization III
   * aggregate block I/O request
   * found out random access reads across multiple files are slower than reading files one by one.
   * we sort bricks by each brick's file name, so access to one file can take place all together.
  • performance optimization IV
   * RGB format without shader
   * we used to use shader programs to combine channel data.
   * we give up the control of each channel, however, we get more performance
   * RGB format is usually an optimized format in OpenGL
  • multiple players
   * removed all the global variables so that multiple instances of rendering class can co-exist.
   * created two Geode class and they run successfully in covise
   * MultiVirvoNode.[cpp|h]
  • plugin improvement
   * added an menu item so the plugin can hold loading all the data when initializing and start loading when users request
   * added pixelToVoxel ratio and brickLimit control