6.375 Ray Tracing Hardware AcceleratorChun Fai Cheung, Sabrina Neuman, Michael PoonMay 13, 2010AbstractThis report describes the design and implementation of a hardware accelerator for softwareray tracing using Bluespec System Verilog compiled onto an FPGA. The hardware accelerator issubstituted for the intersection test function in a ray tracing software program called POV-Ray.Sce-Mi, written in C++, is used to interface the POV-Ray software with the FPGA hardwareaccelerator. Scenes with multiple shapes and multiple types of shapes were successfully ren-dered, and performance estimates from preliminary testing results indicated that the hardwareaccelerator could indeed accomplish its task faster than the purely software implementation.1 BackgroundIn real life, rays of light start at a light source and refract or reflect off of objects in their path. Someof these rays eventually terminate at the eyes of a viewer, whose image of the scene is assembledfrom those rays. Recreating this phenomena to render a virtual image is very inefficient, becausemany ray paths do not return to the viewer at all. The much more efficient solution is a backwardsapproach, known as ray tracing.Ray tracing is a technique in image rendering where the path of individual rays of light are traced,starting from the viewer, to each pixel in the scene, refracting or reflecting off of objects in theimage and terminating at the light source. Although this yields very high quality photorealisticimages, ray tracing is not currently in widespread use for real-time rendering applications such asmodeling software and video games because it is computationally intensive when written in soft-ware, and frames will not render quickly enough at high resolutions.2 Project ObjectiveOur goal is to implement a hardware accelerator on an FPGA to work in conjunction with raytracing software, to speed up the computation necessary for ray traced rendering of images. Weuse an open source software ray tracing program, called POV-Ray, and an FPGA to implementour hardware accelerator for the software.There are several benefits to using an FPGA for this application. First, the ease-of-use that work-ing with an FPGA affords makes hardware design, development, and prototyping fast and low-risk.Second, the FPGA’s performance is a conservative performance indicator when compared to cus-tom hardware. A hardware accelerator design implemented on an FPGA that meets the necessarytiming specifications for high performance ray tracing procedures will likely demonstrate signifi-cantly more impressive performance when implemented in custom hardware.We want a single hardware accelerator to alleviate the computational burden of the software raytracing algorithm, and successfully interface it with the software so that images render correctly.We chose to accelerate ray-shape intersections because they are the bulk of computations performedand because they lend themselves better to be implemented in hardware compared with anothercomputationally expensive operation, bounding box calculations.Once we had a basic implementation of our main goal, we made several refinements to our hardwareaccelerator for higher performance. One performance refinement was to pipeline the ray intersectiondetection test module, to achieve a higher clock speed and greater throughput. Another perfor-mance refinement was to add an additional hardware module that loaded the scene objects to berendered onto the FPGA. By doing this, we save the communication burden of having the softwareconstantly sending all of the objects as well as all of the rays to be tested to the hardware. Nowinstead, the objects in a scene are sent to the FPGA only once, where they are loaded into memorystorage. The objects are then iterated through on the hardware end, and the software is onlyresponsible for sending rays to be tested to the hardware.Figure 1: The ray tracing algorithm builds an image by extending rays into a scene3 High Level Hardware DesignOur basic hardware accelerator is an implementation of intersection testing. The intersection hard-ware accelerator takes as input rays and objects provided by the software, and returns intersectionresults, including the point of intersection and the depth along the ray where the point is found.In cases where a single ray intersects multiple objects, the intersection for the object with theminimum depth along the ray is returned.The high level design of our intersection hardware accelerator is two main blocks– one that performsintersection tests between rays and objects in a scene, and one that iterates through the objectsto be tested for intersections. The object iteration block loads all of the objects in a scene fromthe software once at the beginning of rendering, and then iterates through the stored objects andfeeds them to the intersect test block for testing. This block also receives the intersection dataoutput from the intersect test block, and keeps track of the current minimum depth intersectionfor every ray, in order to return that as a result to the software. The intersect test block receivesthe rays and objects to test as input, and then checks for intersections. It outputs whether therewas an intersection or not, the calculated point of intersection, the depth along the ray that theintersection occurs, and a tag signifying what type of shape was intersected.4 Microarchitecture DescriptionThe hardware accelerator has three main parts: the software-hardware interface layers, the shapeloading and iteration hardware block, and the hardware intersect test block. The following sectionsare an in depth look into the designs of each of these parts.4.1 Software-Hardware Interface LayersThe software-hardware interface consists of three distinct parts, the POV-Ray software, a testbenchlayer and the Sce-Mi bridge. The POV-Ray software’s ray-shape intersection function was modifiedto off-load the ray-shape intersection tests to our hardware accelerator through pipes. A requestpipe is used to send the ray-shape intersection test request messages and shape messages to theC++ testbench and a response pipe is used to receive the ray-shape intersection result messagefrom the C++ testbench.Figure 2: The request flow from POV-Ray to Sce-Mi bridgeThe C++ testbench acts as a translation layer that converts the message data sent from POV-Rayinto data bits understood by the Sce-Mi bridge. The testbench is able to handle two types ofmessages, shape messages
View Full Document
Unlocking...