DirectTrace Architecture

Pipeline and Philosophy

The library has been designed to be low-level, but should be nevertheless easy to use. Programs using the library just need to include a DLL inside their directory, with developers having to include both a .h and a .c file inside their project (and possibly ensure that OpenGL/OpenCL is supported by the platform). A primordial choice has been to focus on a low-level, OpenGL-alike API. For instance, the API does not implement its own window manager, or any kind of interface. The API is not too much of a black-box either, and a good, OpenGL-aware programmer should be able to guess what is happening inside the API. Both the API syntax and pipeline are similar to the OpenGL ones, but we chose to simplify concepts whenever suitable to reduce bugs and maintain high-productivity. Finally, the state-machine aspect of OpenGL partially disappears in DirectTrace. Resource allocations are simplified by using classes. Creating an Image object is as simple as declaring a variable, and copying a buffer is as easy as using the operator=. Some OpenGL concepts have persisted though, like for instance the modelview and the projection matrices.

All in all, DirectTrace provides or will provide all the crucial functionalities needed in a Graphics rendering pipeline. Scenes with materials and various properties can be quickly created, and porting from an OpenGL application should be easy enough. Rays can be setup either from the OpenGL Frustum or light sources, intersections can be found using a single kernel call, and samples can be blended using functions written in regular C or OpenCL .


Even thought a precomputed spatial subdivision data structure is not used, the level of performance is very high. A single core can trace up to 10M rays per second for primary rays, and approximately 1 million random rays per second. We are working on the OpenCL acceleration at the moment, which already show some benefits.

Current State of the API

The two versions of the API (X86-64 bits and OpenCL) are still beta, but with most functionalities implemented, working and stable for typical usage patterns. There is still much to do to improve the library itself. Unlike OpenGL for instance, a wrong usage of the library will crash your program. A typical example would be to read data from a buffer that has not been initialized yet. We plan to implement a few safeguards that will decrease such behavior, but that is something that developers need to consider at the moment. Another missing feature is texture mapping. Developers can still easily implement texture fetching operations from intersection coordinates, but we plan to ease their task by improving the OpenCL/OpenGL interoperability in the OpenCL version. Note as well that OpenCL drivers provided by hardware manufacturers are still far from ideal. A few Graphics Cards have been tested at the moment, but you main want to stick to the latest NVidia generation to be on the safe side if you plan to use GPU acceleration.