GPU Support

As optimized as the Ember implementation is, it still takes some time to render an image at low quality. High quality renders take even longer. Modern GPUs offer tremendous computing power at very low cost. Software libraries to program GPUs for general purpose computing have evolved significantly. This was not lost on the fractal flame developer community, and several attempts had been made to move processing to the GPU. Despite good efforts, all of them fell short in some way or another.

This project aimed to capture the best work done by all developers in various projects and integrate it into one common open source GPU fractal flame renderer. It was named EmberCL to signify that it was a derivation of the Ember library which uses OpenCL.

The list of previous efforts which this project borrows from are:

Flam4

When this project was started, flam4 was the most well known attempt at GPU rendering of fractal flames, it provided libraries written in both OpenCL and CUDA. It implemented all 98 variations from the standard flam3 implementation as well as some basic filtering and color correction. It came fairly close to the original, but did not duplicate it completely. When doing animation, motion blur was omitted. This is because flam4 was implemented as a side add-in for the heavy iteration processing, but was not fully integrated into the process. Further, it was very unstable and would crash randomly.

In more recent times, the flam4 side project has died off and it has a permanent home in Fractal Architect. It has improved significantly and is one of the top fractal flames editors for Mac.

Fractron 9000

Both a library and a fractal flame editor GUI, this program also implemented a portion of flam3 on the GPU using both OpenCL and CUDA. In the interest of efficiency, it took some major shortcuts to produce a final output image. Post affine transforms and final xforms are omitted completely. Each xform is limited to a maximum of four variations. The iteration surface assumes a hard coded supersample of 2. Basic log scale tone mapping is done, but Gaussian density filtering is omitted. Some basic color correction is done but no spatial filtering. Further, it only implements a small, non-parametric, subset of the 98 variations flam3 supports, with one new variation called Orb. Only still images can be produced with no support for animation.

Fractron did however implement an interesting feature that no other GPU implementation did: support for two-dimensional palettes.

It also implemented an interesting hybrid solution for underpowered GPUs. This involved doing iteration calculations on the GPU, but offloading the histogram plotting to the GPU using OpenGL. No other program has done this, however it becomes less necessary as time goes on an all GPUs eventually are powerful enough to do full OpenCL rendering.

In all, despite the shortcuts taken, Fractron produced very nice looking images in a reasonable amount of time and had a very responsive GUI. The xform selection logic and drawing code on the main editor was borrowed from heavily in Fractorium.

Cuburn

Written as a senior project by 4 students at the University of Central Florida in 2011, it attempted to achieve real-time animation of fractal flames. It aimed to produce results as close as possible to flam3, while also being the fastest implementation in existence. Impressively, they managed to achieve both.

However their implementation had a severe shortcoming: it was implemented in pyCuda and only ran on Linux. This meant that it could only be ran on Nvidia cards, and the user had to install numerous pre-requisites just to run the program, let alone do development. The constraint of only running on Linux further limited its adoption as that operating system makes up around 1% of desktop users. Although they achieved performance that was far ahead of any existing implementation, then end product was unusable by most people.

Due to the speed of this implementation, cuburn’s method for iteration is what this project uses.