Difference between revisions of "HanProgressReportSep08"

Latest revision as of 14: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