OpenCL test: rendering the buddhabrot

[amarzo]

I used the OpenCL part of LWJGL to render a fractal animation of the Buddhabrot (a variation of the classic Mandelbrot).

Although the problem is not very well suited for OpenCL (density maps with random access patterns, and I am to dumb to implement Metropolis-hasting) I got some performance improvement over calculating it on the CPU.

Here it is a video showing  the result:
http://www.youtube.com/watch?v=jnh53UYZGe8

In the description you will find a link to more highres screenshots and to the source code.

[CodeBunny]

Ooh, pretty.

Looks very nice.

About what FPS did you get, btw?

[spasi]

Awesome, looks great!

Just a heads-up though, CLKernel.setArgSize(int index, long size) and the low-level equivalent clSetKernelArg(CLKernel kernel, int arg_index, long arg_value_arg_size) will crash when called on the trunk version. This problem has been fixed in the OpenGL ES branch, so better switch to that if you'd like to use OpenCL's work-group local memory (you may have to in order to optimize the implementation for the GPU).

[amarzo]

Ooh, pretty.
Looks very nice.
About what FPS did you get, btw?

Actually about 0.016FPS because it took 24 hours to render. Sorry to disappoint you, Buddhabrot is a very time consuming fractal as it involves calc of density maps for the orbits (sometimes, very long orbits) of billions of points. Of course it is not the best implementation.
BTW you avatar is very cool : )

Awesome, looks great!

Just a heads-up though, CLKernel.setArgSize(int index, long size) and the low-level equivalent clSetKernelArg(CLKernel kernel, int arg_index, long arg_value_arg_size) will crash when called on the trunk version. This problem has been fixed in the OpenGL ES branch, so better switch to that if you'd like to use OpenCL's work-group local memory (you may have to in order to optimize the implementation for the GPU).

Thank you for the suggestion but I do not know if Buddha will improve using working groups (for shared memory or for memory write coalesce). For sure other fractals will take advantage of this, but instead of using some succession for every pixel and giving it a color depending on how many iterations it take to diverge or converge (seasoned with your favorite coloring technique), Buddha is more “hard”. Broadly speaking, for determining the color of a pixel you count the number of orbits (of any other points) which pass through it.

Of course I am lazzy and noob and there are some statistical techniques for estimating points which orbits will pass through a certain point (Metropoli-hasting), and therefore using more standard and GPU-friendly techniques. I have not seen any implementation of this, but it would be great to see a buddha in real-time.

I promise to notify here when I see one

[CodeBunny]

Ooh, pretty.
Looks very nice.
About what FPS did you get, btw?

Actually about 0.016FPS because it took 24 hours to render. Sorry to disappoint you, Buddhabrot is a very time consuming fractal as it involves calc of density maps for the orbits (sometimes, very long orbits) of billions of points. Of course it is not the best implementation.
BTW you avatar is very cool : )

Nice render, then.

Thank you. The rabbit is the mascot of the soon-to-be released open source 2D game engine I'm making.