Buddhabrot on GPU

[cbuchner1]

I run much more thread than available core (usually 1 million per frame, much more if i have a low (<1000) maxiter).
When a tread complete, a new thread pick a new pair of random number (according to its unique global_id) from the 2 randomBuffer.
The 2 randomBuffers are filled by another kernel. So i never need to transfer randoms from host to device.

It may take longer that you expect for a new thread to start up:

The scheduling granularity of the nVidia hardware is in so-called "warps" of 32 threads. So while one thread within a warp is still active but the other threads have terminated, these threads will sit idle until the last working thread finishes.

A similar inefficiency exists at the block level in nVidia's Compute Capability 1.x hardware: New blocks are only fed to the GPU by the driver when about half of all active blocks have terminated (as an example you have 14 multiprocessors on a nVidia 8800GT, so 7 blocks must have terminated before new blocks are fed to the hardware). On Fermi architecture (Compute Capability >= 2.0) this behavior has been improved (block scheduling was moved from the driver into the hardware, which they named "Gigathread engine")

This should also apply to OpenCL in much the same way, even though the naming of threads, warps and blocks may be slightly different (a "block" becomes a "work group" in OpenCL)

I still can't get my GTX 460 to work under Linux or Windows XP Prof. (seems my mainboard BIOS doesn't like this card!), so I am starting to do Buddhabrots in CUDA on my laptop's 9600M graphics card (32 shaders). I will be trying to utilize shared memory as much as possible to prevent the scattered writes to global memory.

[ker2x]

in progress ... 175k sample/s at 100k max iteration



A deeper zoom on the left "bulb" of the above pic at 10k iterations . (took a few hours to render)

[cbuchner1]

in progress ... 175k sample/s at 100k max iteration

How do you define sample? Does a sample represent a scattered write to the accumulation buffer, or is it a complex starting point for an orbit?

Is this number for your 8800 card or for the Ion2 ?

[ker2x]

in progress ... 175k sample/s at 100k max iteration

How do you define sample? Does a sample represent a scattered write to the accumulation buffer, or is it a complex starting point for an orbit?

Is this number for your 8800 card or for the Ion2 ?

numbers for the 8800GTX.
Technically, a "sample" is a thread. so it is what you call "a complex starting point for an orbit".

[ker2x]

Et la lumière fut ...

Color \o/ 

[ker2x]

Okay, a nicer one. around 10mn of computation on my Laptop.
Sorry about the ugly jpg compression, it's a screenshot, i need to implement a way to print the real result (in HDR if possible) with a lossless compression.
Source code available here : http://github.com/ker2x/WinBuddhaOpenCL

[cbuchner1]

Nice, I also got some first B/W images today with CUDA. Using my tiled rendering method in shared memory seems to slow things down currently.

I also tried two buddhabrot variations:
1) I multiplied the contribution of each orbit with its length.
2) I divided the contribution of each orbit by its total length.

One could combine the original buddhabrot with these two variations in the three R,G,B channels to result in a much different colorization.

I could also imagine using some nonlinear functions, such as gaussians centered at different locations on the "number of iterations" axis, that emphasize different orbit lengths for the R,G, and B color channels.

[ker2x]

Nice, I also got some first B/W images today with CUDA

I also tried two buddhabrot variations:
1) I multiplied the contribution of each orbit with its length.
2) I divided the contribution of each orbit with its total length.

Yay \o/
I'd love to see your progress and results. I'm planning to try cuda too.
Feel free to post your dev diary here (with code if opensource (hopefully)).

[cbuchner1]

Selectively plotting only the contributions for orbits of length <= 10 iterations and in the second picture those of length 10 to 20.
Or how about this third image: Selectively plotting only the 10th step from ANY orbit below the cutoff (256 iterations).

Combining all of this opens some interesting new ways of coloring. Creating animations by generating image sequences with parameter sweeps of the above restrictions is also possible. One could also compute "smooth" orbit lengths (instead of integer ones), which would allow for more gradual parameter sweeps.

So as you see I am currently more interested in exporing variations of the original Buddha- and Nebulabrots. The original horse has been beaten to death already, I am try to cross-breed some donkeys and zebras now.

I have a last one for you: Plotting iteration 5 of all orbits of length 100 and greater (but below the cutoff of 256)

[ker2x]

I have a last one for you: Plotting iteration 5 of all orbits of length 100 and greater (but below the cutoff of 256)

Very nice, and interesting
My code should be able to do the same thing. i'm going to try

[ker2x]

A new colorfull buddha :


Red : 20k -> 60k iterations
Green : 60k -> 100k iterations
Blue : 100k -> 200k iterations

[kram1032]

those are some nice variations

[cbuchner1]

There are more things I want to try tomorrow.

I could try to restrict my random generator to a specific region in the complex plane. So the set of starting points for iterating will be from a small, confined region - so this will render only a small part of the orbits contributing to the "complete" buddhabrot.

I could then move this source region over the complex plane and watch the resulting buddhabrot change its shape. Also I could pick three different source regions and generate three distinct color channels from.

But first I need a way to create proper HDR exposures, save frames, combine three grayscale frames to a color image and assemble an  animation from this source data. Plenty of "boring" routine jobs before I get the exciting animations.

[ker2x]

i still have a problem with coloring, so i added just a pinch of contrast with irfanview :



the same one with heavy-duty postprocessing (reveal interesting details) :



same position, differents iteration :

[cbuchner1]

so this will render only a small part of the orbits contributing to the "complete" buddhabrot.

No longer the average buddhabrot :

-all orbits start within axis-aligned ellipse bounded by (-2.0, 2.0), i*(-1.0, 0.0).
-only plotting orbits length 100 or more (but below cutoff 256)
-weighting each orbit with a factor proportional to ln(orbit length)

I have started looking into the Metropolis-Hastings algorithm to speed up zooming. I have also split off my random number generation from the actual rendering code and I think I can fully integrate this algorithm into the random generator. EDIT: yup, works.