cs6620 Project 1.

Abe Stephens.

Required Images



Image Viewer Screen Shot:


Description

Design choices:
I implemented three versions of the renderer, two multi-threaded versions, and one very simple single threaded version. The performance numbers were taken from the single threaded version. Both multi-threaded versions share the same rendering code, however one uses a Fox front-end while the other has a command line interface. The fox front-end pictured above allows a user to render the images to an on screen buffer. The rendering takes place in a separate thread from the user interface. The image buffer is shared between the threads and the user interface may be configured to refresh from the image buffer every second using a menu option. The front-end also contains a text input area which a user will eventually be able to enter configuration command into. This functionality is similar to that in my gpu workbench.

I implemented a skeleton render surrounded by several utility classes. I have classes, Point, Vector, Color in a common tools library. Points and Vectors are binary compatible, however, appropriate operations are defined between them to limit their semantics. (For example subtracting two points produces a Vector) The renderer static library contains the ray casting code along with a virtual frame buffer class. This class is implemented by both FrameBufferPNG to output directly to a .png file and SRTImagePlane which is an FXVerticalFrame component and displays the image on the screen. GenericRenderer implementations are contained within the fox front-end and render on to either type of frame buffer. The Frame buffer class contains two methods for updating the image, write(...) and commit(...). The write method is invoked by the renderer when the value for a single pixel is computed. The commit method is invoked when the entire frame is complete. For interactive viewing, from the fox front-end, write methods deposit finished pixels on a client side buffer, if the user has selected to refresh the output image every second, the writes collect in the buffer and it is copied to the server once per second. When commit is invoked, the image is updated the next time that the widget refreshes.

Since the rendering code is encapsulated behind a class which implements GenericRenderer, both the command line version and the fox front-end may share the same rendering code. Although the render must run in a separate thread behind the fox runtime, the command line version of the code may manually call the thread start function and run in a single thread if desired. I expect that I will implement a mailbox work queue and see how the renderer scales on multiple threads for the next assignment.

The software uses Teem/Nrrd to output PNG images. It is built using cmake.

Performance Template

Notes on performance:
There was not a substantial difference between the command line and image viewer versions of the program. In all I implemented three versions, two which used the same code base and ran the rendering code in a separate thread, and a third single threaded version. Using a separate rendering thread was necessary to integrate the renderer into the Fox toolkit. There was however a substantial difference between compiler flags combinations.



Natually, debug mode incurs a significant performance penalty. Release mode, which is the default optimized configuration for Visual Studio, is also expensive.

Flag
 Meaning
 Default Release Mode Setting
/Ox
 Full Optimization (marginally better than /O2)
 /O2
/Og
 Global Optimization
 No
/Ob2
 Auto-Inlining
 (side-effect of) /O2
/Oi
 Enable Intrinsics
 No
/Ot
 Favor Fast Code
 /Os (favor small code)
/G7
 Optimizie for Intel Pentium 4
 /GB (for all Pentium family)
/GL
 While Program Optimization
 No
/arch:SSE
 Use SSE Instructions where possible.
 No