1 / 15

Render Cache

Render Cache. John Tran CS851 - Interactive Ray Tracing February 5, 2003. Main Points. Layering interactive display processes over high quality but slow renderers is an increasingly popular idea

ada
Download Presentation

Render Cache

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Render Cache John Tran CS851 - Interactive Ray Tracing February 5, 2003

  2. Main Points • Layering interactive display processes over high quality but slow renderers is an increasingly popular idea • Stores recent shading results from the underlying renderer as colored 3d points in a fixed size cache • For each frame, reproject those points onto new image plane and filter results • Implemented completely in software! • (Self-proclaimed addictive interface)

  3. Separating the Renderer from the Display Process • See Figure 1, paper 1 • Reduces framerate dependence on the speed of the renderer • Display provides interactive feedback to the user even when the renderer itself is too slow • Display process caches previous frame results in the form of 3D colored points – “Render Cache” • Can use any renderer (ray tracing, path tracing…) • Only requirement is that renderer must be able to efficiently compute individual rays or pixels

  4. Problems with Reprojection • Pixel to point mapping is not a bijection • Especially true the faster the camera moves • Occlusion errors • Non-diffuse shading

  5. Image Generation • Project render cache points onto new image plane • Transform is specified by the application • Depth culled using a 3x3 grid around the pixel • Compute average depth, and compare this pixels depth to that average • Smoothing Filter • 3x3 weighted grid (4, 2, 1)

  6. Where to sample? • Assume renderer is slow relative to the frame dimensions • Priority image • Priority based on pixel’s age (oldest pixels will be updated sooner) • Priority for some points set by the values in the render cache; the others are set by interpolation on neighbors • Pixels with no valid neighbors receive the max priority • If pixel’s priority is over a certain threshold, then that pixel is requested as a sample from the renderer

  7. The Render Cache • Fixed size slightly larger than the number of pixels to be displayed • New points that are resamples overwrite that point in the cache • They do not use LRU; instead they do LRU of a group of 8 points, which are rotated in a round-robin order

  8. Mismatch ratio • Number of pixels in a frame / number of new samples produced by renderer per frame • Render Cache is best for handling high mismatch ratios (up to 64)

  9. Implementation and Results • Used 195Mhz R10000 in an SGI Origin 2000 • 256x256 @ 14fps • Uniprocessors would have to split time between Display and Renderer • Best for multiprocessors • Implemented with shared memory, although mentioned message passing as possible • Used machines with 1 to 60 processors

  10. 2002 Update • Predictive sampling • Split projection/tiled z-buffer for memory coherence • Prefilter • SIMD optimization

  11. Predictive sampling • Use predicted camera parameters • Project onto a lower resolution image • Create sample requests for any image that did not project • Use every nth sample if too many samples for this frame • Rely on application to provide the predicted camera

  12. Tiled z-buffer • Break up the frame into tiles for memory coherence • Sort-first

  13. Image Prefilter • Use a 7x7 uniform filter instead of 3x3 • Handles sparse regions better • Larger prefilter is only used where the 3x3 filter fails

  14. More speedups • Point Evictions • Used to keep points in cache until they were over written • Now, can evict a point if it gets too old/stale • SIMD optimizations

  15. Conclusions • New version can render 512x512 faster than the old version rendered 256x256 • Half of this speedup is probably because of SIMD

More Related