Jan 21, 2010:
This is the software renderer for Orkid I just started. It is a side project to address my interest in software renderers. I also have a practical need for it, and I will not be rushing this out. I made a simple raytracer for baking lightmaps in the last project I worked on and this renderer when finished will likely take its place. Previously, I had also tried using Pixie and Gelato (REYES renderers) for baking lightmaps, AO, etc…. And while they do work, they were buggy and the way they go about baking to a map with non overlapping UV’s is horribly inefficient. They are designed to render to a camera view or to a ‘spatial database’, and in either case you have to turn visibility culling and view based dicing off and they end up doing way too much work (time and memory) for what you need. The ideal baker rasterizes triangles directly into UV space. The ideal baker can still use raytracing or whatever other method it needs to compute the color, but the decision of which pixels to actually compute falls to the UV space rasterizer. I am sure these are issues that Turtle has had to deal with.

This renderer is heavily threaded via a thread pool with concurrent job queues and other atomic building blocks. The transformation pipeline is data parallel (fixed at 64 jobs). Each job handles 1/64th of the polys. Each transformation pipeline job distributes the poly to the appropriate tiles (buckets). Each bucket can atomically add polys without locks, so that each bucket can receive polys from multiple threads efficiently and concurrently. The tile rasterizers are also data parallel. The number of jobs is computed dynamically based on screensize. It divides the screen up into NxN pixel tiles (currently N=128). Task parallelism via the pipeline pattern is coming soon. It will require multi-buffered buckets.

It started out using a Z buffer, recently I switched to a REYES style A buffer/Compositor/Hider for per pixel z sorted translucent fragment lists. I will probably end up making it configurable, the Z buffer is much faster and will still come in handy sometimes. A Renderman like shader language or environment is planned. I plan on doing light shaders, surface shaders, atmospheric and volume shaders. I’m not sold on displacement shaders yet (normalmaps seem fine for the kind of things I plan on using this for).. I will also add in a trace family of functions for ray-tracing, AO and SSS baking.

All performance figures are for a dual Xeon 2.26ghz E5520 machine with all 8 cores (16 ht cores) enabled running Windows7 X64 with a 32bit executable. It is not SIMD optimized yet. I am also not using indexed triangles yet (and therefore also not using a post xform cache). While performance is important, I will be primarily aiming for image quality. Once I get the basic features ironed out and solid, I am going to move a few pipeline stages over to OpenCL/CUDA. I could probably save a lot of time by using CUDA/OpenCL directly as the shading language. The model is shown here with only back faces so you can see the internal complexity of the object (usually it would be hidden by the outer walls). The test model has approximately 350K triangles.

Note: some video captures are colored incorrectly because Fraps has a swizzling/surface format bug with direct2d, I believe R and B are swapped. I have recently switched to using ffmpeg, these captures are both fine and dandy.

Spherical environment mapping working in OpenCL with 2d image objects and samplers. I was very surprised to find out OpenCL does not have float3 support, so I have to use float4 for normals. Also the NVidia OpenCL compiler is very buggy. It chokes horribly on commented out code.

Next I am going to see if porting the triangle scan converter and aa resolver to OpenCL help performance.
Sharing buffers between stages should get me less host<>opencl data movement traffic.
Or maybe I should do a ray marching volume shader. So many choices…

The Renderer is now computing fragments in OpenCL. What a PITA! Dealing with broken NVidia SDK’s (I had to ‘hot rod’ the NVidia SDK with the OpenCL headers and libs from the ATI stream SDK (see this post ). At least it works now!

It is currently a bit slower on a Geforce260core216 than a 2x Xeon E5520, This is most likely due to:

• Very simple shader (barycentric->color with no conditionals), => The math/overhead ratio is lower. ( source code to shader: here ) .
• The need for locking (OpenCL cannot enqueue kernels from multiple threads, so only 1 tile buffer can access the OpenCL device at a time). The CPU version needs absolutely no locking, as it relies upon atomic operations when dealing with concurrent containers.
• PCI-Express data movement overhead.
• Bottleneck elsewhere in the pipeline.
• Shiny new untested OpenCL drivers?.

The Performance gap should shift drastically into OpenCL’s favor when I get a more complicated shader in..

Our second shader! It is written in C++ (not in a shading language). Normals interpolation working. Texture/Samplers working. Spherical environment mapping, etc… You can really see the A-Buffer’s perfect depth sorted translucency in this video.

Our first shader! It is written in C++ (not in a shading language). The full shading pipe is not yet implemented. That said, it is still a shader!
It is a composite of object-space face normals, a grid in object-space, and a single octave of object-space noise modulating another grid.
Spent way too much time fiddling with ffmpeg and YouTube trying to get a decent quality video. At least now I have a reasonable transcoding process ironed out..

The A-Buffer is working and the Z-Buffer is disabled. Obviously, performance dropped quite a bit. Every fragment now has to allocate a rend_fragment struct from a fragment pool and add it to a per pixel linked list. There is a single fragment pool per tile buffer (and therefore 1 per thread). The fragment pool does help quite a bit by batching up heap allocations. The fragment pools have a reset function which just resets counters so that next frame the recycled fragments are used first and heap traffic is greatly reduced. After the tile has computed all fragments then they are composited in the AA resolve step. I don’t have fragment Z sorting working yet, I am undecided on if it will happen on the fly at list addition or as a postprocess in the composite phase. Maintaining good data and instruction cache locality would lead me to try the postprocess phase first (probably using a radix sort).