This page describes how LuxRender organizes their OpenCL kernels. Please note that OpenCL LuxRender runs 4 times slower then CPU.
LuxRender is split into two parts LuxRays and LuxCore. LuxRays provides Ray Intersection, LuxCore the path tracer.
Path trace process (kernels)
- Clear film
- Initialize random seeds
- Initialize task buffer
- Send start film (optional)
- Render loop:
- Receive film buffer (optional; for updating sample counts and displaying intermediate result)
- TraceRay (See LuxRays)
- Path Kernel; in sequence the next (micro) kernels are called. It is a finite state machine where every kernel does a transition check
- Receive film buffer
The path kernel generates rays and evaluates those rays in an finite state. When rays are completed it generates new rays.
The OpenCL source code is dynamic and can trigger a recompilation when
- Texture evaluation code changes
- Material evaluation code changes.
LuxRays has its own clContext. LuxCore can push the rays it wants to calculate to LuxRays in a RayBuffer. LuxRays uploads the RayBuffer to the device, enqueues the kernel ('Accelerator_Intersect_RayBuffer') and read the result back to host ram.
The kernel supports two acceleration structures (MBVH and BVH). MBVH is selected when instance support or motion blur is needed.
For memory management LuxRender uses a similar construction as Cycles. It creates pages and store the needed data in these pages. A big difference is that the kernel parameters are generated (and therefore the kernel) based on the number of pages that actually contains data.
They have two kind of pages.
- only containing vertices
- only containing BVH nodes