Personal Information

Name: Andrew Price
Email Address: andrewprice@andrewalexanderprice.com
Website: www.andrewalexanderprice.com
Forum Nickname: MessiahAndrw

Distributed Rendering

Synopsis

YafaRay is a free, open source ray tracing program. Through the Google Summer of Code 2010 program I will aim to implement parallel rendering capabilities to the ray tracer to take advantage of multi-threaded and network rendering to significantly improve rendering performance.

Background

Rendering computer-generated images via ray tracing is a time consuming process that requires a lot of processing power. As the growth in CPU clock rates has slowed in recent years it is unlikely that single-threaded ray tracing techniques will see an improvement in performance in the near future. As increasing the number of cores in processors has become the new trend and networks are common in most businesses and homes there is a significant advantage in writing parallel code which can take advantage of these developments. The techniques used in ray tracing are perfect for adapting into a parallel system.

By distributing the process of ray tracing over a collection of computers on a network, known as a render farm, it becomes possible to render images very quickly compared to on a single computer. The performance of a render farm can be increased by simply adding more computers. Allowing YafaRay to be used in a render farm environment makes it a more attractive competitor to commercial ray-tracers, especially in the television and motion film industries where a large number of scenes must be rendered in a relatively short period of time.

Implementation

YafaRay already has some multi-threading capabilities however my goal is to implement a unified solution for both multi-threaded and network rendering. An important criterion for my implementation is to ensure the difference between a thread running on the same computer and a thread running on a remote computer is as transparent as possible to both the developers and end users. This criterion is important to simplify the code, avoid redundant code, and to make it as easy as possible for other developers to write parallel code in YafaRay with ease. To avoid disambiguation the term “processing unit” will be used to represent a worker thread regardless of if it is running on a local or remote computer.

The computers containing processing units that will contribute to the rendering process will be known as slaves, while the computer through which the user initiates the render will be known as the master. Clients and masters will find each other by connecting through a computer known as the client manager. The client manager’s sole responsibility is managing slaves and allocating them to masters. Multiple masters can connect to the same slave, in which case slaves can be evenly distributed between masters or the masters are queued until a slave becomes available depending on the client manager’s configuration. Masters and slaves will communicate directly with each other unless they cannot (such as a NAT issue) in which case traffic will be routed through the client manager but an overhead penalty will apply. Masters and slaves will be able to exist on both local and wide area networks and a mixture of the two as long as they are able to communicate with the client manager.

The master and client manager are separated because situations will exist where several work computers will wish to use a single render farm. By allowing each work computer to be a master the user will be able to initiate a render on the render farm directly from their local computer rather than have to upload the scene to a server. The client manager can be configured to only accept local masters if a situation exists where the latter is preferred. A computer can be a master, slave, client manager, or a combination thereof.

I will be required to develop the slave frontend for YafaRay so that the computer can contribute as processing units to the master. I will also be required to develop a client manager for YafaRay that will organize the slaves and distribute them to masters. Then I will also have to modify YafaRay so that it can act as a master and distribute parallel tasks across slaves. On top of this I will develop a command-line front end to the client manager so the properties of the client manager (such as the slave distribution algorithm being used, black/white-listing masters, and logs and statistics) can be modified and viewed while the client manager is running.

While some things would be very simple to parallelize such ray tracing individual rays (and the functionality for doing so can be added through the virtual functions of tiledIntegrator_t), other algorithms will require careful planning (such as avoiding an unnecessary amount of network traffic for algorithms like photon mapping and motion blur). For the most part, most techniques used in ray tracing can be parallelized.

YafaRay splits rendering passes into tiles and the rendering of each tile is independent from other tiles, so these tiles become the perfect unit to distribute to processing units to run in parallel. Before the master begins handing out tiles to processing units, it must ensure each slave contains the necessary resources. For photon mapping each slave must have the scene’s geometry in memory, and for ray tracing each slave must have the scene’s geometry (which will still be in memory from the photon mapping pass), the photon map, as well as the required textures. Slaves will either cache the output (such as a local photon map) of the local processing units and send the result back to the master at the end of the pass, or reply with the result as soon as a processing unit has completed a tile (such as when ray-tracing). The latter is preferred due to the risk of losing rendered data if a slave goes offline while a pass is being rendered, whereas the former will result in lower network traffic since the result can be better compressed.

Distributing resources such as textures and geometry information at the beginning of each pass to the slaves can create considerable overhead, especially on network traffic. Multicasting will be used on local area networks where available to ease sending the same data repeatedly to each slave. Having each slave cache resources is also a very good idea; however that is beyond the scope of my Google Summer of Code project.

Parallel rendering will not affect the end user’s perspective of the rest of YafaRay’s features.  It will also intrude minimally on the other features of YafaRay from a developer’s perspective. The proper constructs will be provided for sharing variables and parallelizing tasks across several processing units. In the case that an algorithm cannot be parallelized then the developer will still be able to write single-threaded code until a parallel alternative is found, but in this case there will be no performance advantage and this code will run purely on the master.

Workflow and Usability

From the system’s perspective:

·         Each slave connects to the client manager.

·         The master connects to the client manager and requests slaves.

·         Slaves are allocated to the master and appear as processing units to the master.

·         For each stage of the rendering pipeline on the master:

o   Distribute the resources required for this stage to each slave.

o   For each parallel task that must be done:

§  Master allocates the task to a processing unit.

§  Processing unit performs the task.

o   Slaves return the result to the master.

·         Save/display the final image.

·         The slaves notify the client manager that they are free.

·         The client manager allocates the slaves to another master or if no master is waiting the slaves are sent to sleep until a master is available.

From a user’s perspective wanting to render an image:

·         The user exports the scene to YafaRay.

·         During the exporting process the user specifies the address of the client manager (such as through the Blender YafaRay exporter interface or as a command line argument to yafaray-xml).

·         The user’s computer now acts as the master and the image is rendered.

·         The final image is saved/displayed.

From a user’s perspective wanting to set up a render farm:

·         The user launches the client manager software on a computer designated as the client manager.

·         The user ensures the network is configured so all potential masters and slaves can communicate with the client manager.

·         The user launches the slave software on each computer to use as a slave and passes the address of the client manager as a command line argument.

·         The user distributes the address of the of client manager to other users that wish to utilise the render farm.

Development Schedule

Before GSoC:

o   April 27
Begin design document.
Brainstorm implementation paths to take with other developers.
Research papers on parallel ray-tracing.
Familiarize myself with YafaRay’s code and submission policies.

GSoC (week by week):

o   May 24
GSoC begins.
Begin design of network protocols.
Begin skeleton code.

o   May 31
Finish class and implementation designs.

o   June 7
Finish skeleton code and Blender interface.
Finish first draft of network protocols.
Begin the slave frontend, client manager, and master for YafaRay.

o   June 14
Have master that can communicate with the client manager and request slaves that appear as processing units.

o   June 21
Have each slave and master share resources and implement calling mechanism for running tasks on process units.
Test render each process unit individually.

o   July 5
Milestone 1.
Have basic direct lighting ray-tracing rendering in parallel across processing units.
Complete and publish benchmark.

o   July 12
Mid-term evaluation.

o   July 19
Ensure all features are successfully rendering.

o   July 26
Milestone 2.
Submit client manager utility.
Submit user documentation.

o   August 2
Bug-fixing, testing, benchmarking, and optimising.

o   August 16
Milestone 2.
Ensure all deliverables are submitted.
GSoC ends.

Done So Far

·         Familiarized myself with the YafaRay ray-tracer inside of Blender and rendered several scenes.

·         Checked out the SVN repository.

·         Set up a development environment and successfully built the code from source.

Deliverables

·         Source code to build the following programs:

o   Stand-alone command-line YafaRay ray-tracer for slaves.

o   Command-line YafaRay client manager.

o   Command-line client manager configuration utility.

o   YafaRay ray tracer that can act as a master.

·         Python scripts to integrate the network rendering options into Blender’s interface.

·         Developer documentation covering the network protocols and specifications used.

·         User documentation covering how to use the network renderer.

·         Benchmarks and tests results.

About Me

I’m a 21 year old postgraduate student at the University of Adelaide in Adelaide, South Australia. I graduated my Bachelor Degree in Interactive Entertainment (majoring in Games Programming) from Qantm College in Brisbane, Queensland, Australia in 2009 and I have since returned to studying to focus on Computer Science. I’m currently undertaking my Graduate Diploma in Computer Science with the expectation of completing my Masters of Computer Science in 2012.

I have had experience in a variety of facades of Computer Science, from operating system and compiler development to games and level editors. One of my proudest projects is the Mercury Game Framework 2 which taught me a lot about real-time rendering techniques and parallel design. I was one of three programmers on the student game, Debug, which won the Best Unsigned Game at GameConnect: Asia Pacific 2008.

A have a background in agile software methodologies due to my game development background and I understand the importance of design before implementation.

I wish to specialise in parallel algorithms and computer graphics, which is why I believe implementing parallel rendering in YafaRay is both a challenge and a perfect fit for me.

As an intern programmer at Star City Media I wrote several exporter tools for 3DS Max and managed a rendering system used to produce an animated show. The experience I had there can allow me to understand what would be required for YafaRay to be used in such an environment, which is also what motivated me to choose YafaRay as my project.