Quaternion Julia sets and GPU computation.

Subblue has released another impressive Pixel Bender plugin, this time a Quaternion Julia set renderer.

The plugin can be downloaded here.

Quaternions are extensions of the complex numbers with four independent components. Quaternion Julia sets still explore the convergence of the system z ← z2 + c, but this time z and c are allowed to be quaternion-valued numbers. Since quaternions are essentially four-dimensional objects, only a slice (the intersection of the set with a plane) of the quaternion Julia sets is shown.

Quaternion Julia sets would be very time consuming to render if it wasn’t for a very elegant (and surprising) formula, the distance estimator, which for any given point gives you the distance to the closest point on the Julia Set. The distance estimator method was first described in: Ray tracing deterministic 3-D fractals (1989).

My first encounter with Quaternion Julia sets was Inigo Quilez’ amazing Kindernoiser demo which packed a complete renderer with ambient occlusion into a 4K executable. It also used the distance estimator method and GPU based acceleration. If you haven’t visited Quilez’ site be sure to do so. It is filled with impressive demos, and well-written tech articles.

Transfigurations (another Quaternion Julia set demo) from Inigo Quilez on Vimeo.

In the 1989 Quaternion Julia set paper, the authors produced their images on an AT&T Pixel Machine, with 64 CPU’s each running at 10 megaFLOPS. I suspect that this was an insanely expensive machine at the time. For comparison, the relatively modest NVIDIA GeForce 8400M GS in my laptop has a theoretical maximum processing rate of 38 gigaFLOPS, or approximately 60 times that of the Pixel Machine. A one megapixel image took the authors of the 1989 paper 1 hour to generate, whereas Subblues GPU implementation uses ca. 1 second on my laptop (making it much more efficient than what would have been expected from the FLOPS ratio).

GPU Acceleration and the future.

These days there is a lot of talk about using GPUs for general purpose programming. The first attempts to use GPUs to speed up general calculations relied on tricks such as using pixel shaders to perform calculations on data stored in texture memory, but since then several API’s have been introduced to make it easier to program the GPUs.

NVIDIAs CUDA is currently by far the most popular and documented API, but it is for NVIDIA only. Their gallery of applications demonstrates the diversity of how GPU calculations can be used. AMD/ATIs has their competing Stream API (formerly called Close To Metal) but don’t bet on this one – I’m pretty sure it is almost abandoned already. Update: as pointed out in the comments, the new ATI Stream 2.0 SDK will include ATIs OpenCL implemention, which for all I can tell is here to stay. What I meant to say was, that I don’t think ATIs earlier attempts at creating a GPU programming interface (including the Brook+ language) are likely to catch on.

Far more important is the emerging OpenCL standard (which is being promoted in Apples Snow Leopard, and is likely to become a de facto standard). Just as OpenGL, it is managed by the Khronos group. OpenCL was originally developed by Apple, and they still own the trademark, which is probably why Microsoft has chosen to promote their own API, DirectCompute. My guess is that CUDA and Brook+ will slowly fade away, as both OpenCL and DirectCompute will come to co-exist just the same way as OpenGL and Direct3D do.

For cross-platform development OpenCL is therefore the most interesting choice, and I’m hoping to see NVIDIA and AMD/ATI release public drivers for Windows as soon as possible (as of now they are in closed beta versions).

GPU acceleration could be very interesting from a generative art perspective, since it suddenly becomes possible to perform advanced visualization, such as ray-tracing, in real-time.

A final comment: a few days ago I found this quaternion Julia set GPU implementation for the iPhone 3GS using OpenGL ES 2.0 programmable shaders. I think this demonstrates the sophistication of the iPhone hardware and software platform – both that a hand-held device even has a programmable GPU, but also that the SDK is flexible enough to make it possible to access it.

6 thoughts on “Quaternion Julia sets and GPU computation.

  1. Thanks. Now I just need some nice Windows drivers so I can get aboard the GPU train ­čÖé

    I don’t suspect I’ll be getting involved into low-level GPU programming, though – I’d rather use some higher level libraries, such as for instance the RTfact real-time raytracing library (some screenshots here). I’ve been looking at a few CUDA/OpenCL tutorials and they look a bit hairy to me.

  2. Disclaimer: I work for AMD in Product Commuications.

    Great piece, even for a non-engineer like myself. Just wanted to point out that ATI Stream is alive and well, not abandoned as indicated in the article. While the move to open source and industry standards is exactly what AMD has supported for GPGPU all along, there is still opportunity for AMD to optimize its drivers and compilers to exploit specific hardware features and help developers produce stronger code. i.e., programmers can \write once\ for OpenCL and then easily compile for different hardware using the vendors’ tools optimized for their platforms. ATI Stream is our brand for hardware and software optimized to leverage those tools and to best take advantage of both the GPU and the CPU, not just GPGPU programming. As the only hardware supplier that offers both CPUs and GPUs, we don’t push developers toward one architecture or another, it’s up to them to decide where their code runs best. Thanks for the opportunity to comment. – Gary

  3. Hi Gary,

    You are right – I was not very clear about the ATI Stream brand. I can see that ATIs implementation of OpenCL will be branded and distributed as part of the new ATI Stream SDK 2.0 – and I certainly do not doubt ATIs commitment to support OpenCL.

    What I tried to say was, that I don’t think there is room for other APIs than OpenCL and DirectCompute in the future. When I said ‘stream’ I was referring to ATIs earlier ‘Close To Metal’ SDK and the ATI Stream SDK 1.4 – which, if I understand it correctly, used yet another GPU language (Brook+).

    I have updated the blog entry to make this a bit more clear.

Leave a Reply

Your email address will not be published. Required fields are marked *