1867

Multi-fragment effects on the GPU using the k-buffer

Louis Bavoil, Steven P. Callahan, Aaron Lefohn, Ao, Claudio T. Silva
Scientific Computing and Imaging Institute, University of Utah
In I3D ’07: Proceedings of the 2007 symposium on Interactive 3D graphics and games (2007), pp. 97-104

@conference{bavoil2007multi,

   title={Multi-fragment effects on the GPU using the k-buffer},

   author={Bavoil, L. and Callahan, S.P. and Lefohn, A. and Comba, J.L.D. and Silva, C.T.},

   booktitle={Proceedings of the 2007 symposium on Interactive 3D graphics and games},

   pages={97–104},

   year={2007},

   organization={ACM}

}

Download Download (PDF)   View View   Source Source   

1076

views

Many interactive rendering algorithms require operations on multiple fragments (i.e., ray intersections) at the same pixel location: however, current Graphics Processing Units (GPUs) capture only a single fragment per pixel. Example effects include transparency, translucency, constructive solid geometry, depth-of-field, direct volume rendering, and isosurface visualization. With current GPUs, programmers implement these effects using multiple passes over the scene geometry, often substantially limiting performance. This paper introduces a generalization of the Z-buffer, called the k-buffer, that makes it possible to efficiently implement such algorithms with only a single geometry pass, yet requires only a small, fixed amount of additional memory. The k-buffer uses framebuffer memory as a read-modify-write (RMW) pool of k entries whose use is programmatically defined by a small k-buffer program. We present two proposals for adding k-buffer support to future GPUs and demonstrate numerous multiple-fragment, single-pass graphics algorithms running on both a software-simulated k-buffer and a k-buffer implemented with current GPUs. The goal of this work is to demonstrate the large number of graphics algorithms that the k-buffer enables and that the efficiency is superior to current multipass approaches.
No votes yet.
Please wait...

* * *

* * *

HGPU group © 2010-2017 hgpu.org

All rights belong to the respective authors

Contact us: