Difference between revisions of "HanProgressReportAugust08"

Revision as of 13:58, 26 August 2008

UP

Deadline

• Aug/11/2008
  • new class restructuring
• Sep/22/2008
  • deadline

TODO

• automatic adjustment of # of bricks loaded at each frame

• revert to memory pool instead of pixel buffer object pool..
  • re-add prefetching thread
  • implement budget based algorithm

• mipmapped video support

   * measuring performance for each step
     - find bottlenecks
     - 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)
   * prefetching bricks?
   * test on starcave by this weekend

• 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

26 Tu

• 65MB/s in a starcave node
  • 11 bricks / frame

25 Mon

• Measured data loading time: 0.1 sec/frame reading O(10) bricks
  • wrote a short program reading sequentially
    • took 137 seconds for 6.5GB, 1200 files of multi-resolution tornado data
    • 47MB/s :(
    • tested with files in local disk
    • with this number, there will be no benefit by prefetching..
• HDD benchmark
• HDD benchmark 2
• Let's say we have 50MB/s bandwidth..
  • one brick is 128 * 128 * 3 byte = 48 KB
  • 50MB/s/(30 frames/s) = 1.66MB/frame = 34 bricks / frame if we *only* consider loading time..
• Assume we need 0.025 second / frame for rendering + all the other steps
  • to achieve 30 frames / second, rendering time will take 0.75 seconds, what is left (0.25 seconds) can be used for data loading
  • as the data loading time is 4 times smaller than the first case,
  • 34 bricks/frame/4 = 8 bricks / frame

12 Tues

• we can control the quality of image rendered
  • parameterize voxel to pixel ratio
  • parameterize the total number of bricks loaded at each frame
• need more performance measurements...

10 Sun

• reimplemented covise plugin with the new MipMapVideoLib
• tested on covise
  • 30 fps when cached
  • below 10 fps when first played

09 Sat

• tested with 750 frames
  • 2M pixel screen
  • horrible performance 3~5 fps without caching
  • second run (with cache) achieves around 30~50 frames per second

08 Fri

• debugged the bug
• tested with 200 tornado data frames and it plays interactively
  • nearest neighbor interpolation causes lots of aliasing especially on lines and edges
  • no prefetching or asynchronous I/O was used
  • trying to come up with an algorithm that limits the total number of bricks loaded at each frame
    • heuristic. there can be a smarter algorithm than one in octreemizer..
    • don't know how much this would impact the overall performance
• generating 600 frames

07 Thur

• refine and debug frame window
  • debugging frame window..
  • data isn't changing...

06 Weds

Done

• generated tornado tiff data sets
• implemented frame window - need test!!!!!
  • opening next 10 frames
  • closing previous 10 frames
  • activating/deactivating BrickReaders
• grpof to find bottlenecks
  • no bad calls, which means my system is IO bounded. =(

August/05/2008 (Tu)

• multi-volume support

   * user interface - need to be able to manipulate one volume at a time
   * new class structures? like in virvo/multirend

• dynamic change in volume control UI
  • hide/show according to volume selection

August/01/2008 (Fri)

Done

• finalized the interface between MipMapVideo library and GUI part