Mandel Machine

[lycium]

Yes, I understand of course that GPUs don't do higher than FP64 internally (and that at greatly reduced speed compared to FP32), but as with CPUs a GPU is Turing complete and can surely do any higher precision computation the CPU can do.

That to me seems like a far better investment of time and energy (known outcome!) than heuristic and approximating methods. As computers get faster and faster, human time becomes more valuable relative to computation time - having to fret over whether you got all the on/off switches and tuning numbers right after every render, versus simply letting it render a bit longer, doesn't seem like a winning long-term strategy.

[Kalles Fraktaler]

GPUs are limited to double precision. Rather restrictive for zoom depths. There is nothing wrong with older methods if you want to go deep and don't mind waiting a couple of hunded times or more longer. 

I do mind waiting. Tick-tock would take 10 minutes to render in 640x360 with fractal extreme on my machine. Kalles fraktaler 2.2.* took 8,5 seconds. That is 70 times faster! With version 2.3.1 it is now rendered in 2 seconds! That is almost 300 times faster! And mandel machine renders this in just less than 1 second, that is 600 times faster. Can you ever do that with GPU? And if you could, how fast could you do it with perturbation on GPU?
So I think it is definitely worth the efforts!

[lycium]

I can't understand why you focus on the 8.5 seconds or 2 seconds and totally refuse to account for the tons of human inspection time (likely on the order of minutes) that something didn't go wrong. And what if you miss a bit that looks a little different? Don't even get me started with apples-to-oranges (completely different programs) comparisons...

Hey man, have your fun of course, I just don't see this as being terribly practical if you can't have faith in the output, no matter how few nanoseconds or whatever the render took...

"A million miles an hour in the wrong direction helps nobody" - American saying?

[Kalles Fraktaler]

I can't understand why you focus on the 8.5 seconds or 2 seconds and totally refuse to account for the tons of human inspection time (likely on the order of minutes) that something didn't go wrong. And what if you miss a bit that looks a little different? Don't even get me started with apples-to-oranges (completely different programs) comparisons...

Hey man, have your fun of course, I just don't see this as being terribly practical if you can't have faith in the output, no matter how few nanoseconds or whatever the render took...

"A million miles an hour in the wrong direction helps nobody" - American saying?

In practice the differencies are almost always none or not visible.
And I would not be impressed anymore of a e228 animation rendered in 6 months on 12 cores, I would just think it would be a waste of time.
But of course anyone can do whatever they want, I only speak for myself.
Tick-tock is just an example and a simple such, other locations takes hours or minutes, or 30 days or 7 hours.
I would never pay for FX or UF and wait for hours/days instead of wait for a minute and do a manual correction in another minute... ;-)

[lycium]

almost always

I guess you're still missing my point about how "almost" is actually really a problem. "It's a million trillion times faster! Except when you notice something is wrong and have to fiddle and make re-renders, so just check every frame of your animation by hand!" Seriously... if that's acceptable to you then fine, but I am just constantly surprised at how that is regarded as a step forward...

Anyway sorry for the skepticism here, but as as a developer of commercial software, I can't imagine myself ever saying to users "yeahhhh well sometimes the output can be bogus in subtle ways, just always check everything with a bunch of test renders and if it's wrong here's a bunch of parameters to fiddle with..."

What is at least completely objective is saying, that you shouldn't compare apples and oranges, i.e. different programs (which can be highly optimised or not) and one which consistently produces the right output, the other which maybe-sometimes-usually-doesn't-need-too-much-checking-to-see-if-it-was-right, etc...

[Kalles Fraktaler]

I guess you're still missing my point about how "almost" is actually really a problem. "It's a million trillion times faster! Except when you notice something is wrong and have to fiddle and make re-renders, so just check every frame of your animation by hand!" Seriously... if that's acceptable to you then fine, but I am just constantly surprised at how that is regarded as a step forward...

Anyway sorry for the skepticism here, but as as a developer of commercial software, I can't imagine myself ever saying to users "yeahhhh well sometimes the output can be bogus in subtle ways, just always check everything with a bunch of test renders and if it's wrong here's a bunch of parameters to fiddle with..."

What is at least completely objective is saying, that you shouldn't compare apples and oranges, i.e. different programs (which can be highly optimised or not) and one which consistently produces the right output, the other which maybe-sometimes-usually-doesn't-need-too-much-checking-to-see-if-it-was-right, etc...

Ok I see your point. Perturbation should never be commersial. And you have to enjoy glitch correcting if you ever want to do animations. But if you do, you will be able to do animations that would have taken years on super hardware within weeks on an ordinary laptop. It's your choice.

[lycium]

My two basic logical objections are:

1. It is disingenuous to talk about 2 seconds render if you always (unless you're into blind faith) have to do a normal-speed test render to make sure the 2 second one didn't go wrong (and even then you might just not have looked long enough and miss it, ending up with a bogus render).

2. Throwing out hard numbers like "weeks" without specifying what program (yes yes, UltraFractal is terribly slow, hooray you successfully compared against an ancient program which at least always gives the right result), and assuming that no better can be done without resorting to brutal approximations that only work some of the time. It's just a completely different thing, sort of like trying to compare an exact solution to the travelling salesman problem running on a 386, to some low accuracy statistical approximation on the GPU that you can't really have any faith in at the end.

[Kalles Fraktaler]

My two basic logical objections are:

1. It is disingenuous to talk about 2 seconds render if you always (unless you're into blind faith) have to do a normal-speed test render to make sure the 2 second one didn't go wrong (and even then you might just not have looked long enough and miss it, ending up with a bogus render).

2. Throwing out hard numbers like "weeks" without specifying what program (yes yes, UltraFractal is terribly slow, hooray you successfully compared against an ancient program which at least always gives the right result), and assuming that no better can be done without resorting to brutal approximations that only work some of the time. It's just a completely different thing, sort of like trying to compare an exact solution to the travelling salesman problem running on a 386, to some low accuracy statistical approximation on the GPU that you can't really have any faith in at the end.

1. You see the glitches easily, no need to do a normal render for comparison.
2. I am comparing with fractal extreme of course, the fastest 'normal' program there is

[Botond Kósa]

I am comparing with fractal extreme of course, the fastest 'normal' program there is

Try Mandel Machine without perturbation, it is up to 2x faster than Fractal Extreme at high zoom levels

Anyway, the consumers of the output of these fractal software will be humans. No need to produce mathematically exact results, just results that are good enough to be indistinguishable from the exact ones. No one even said that perturbation renderers are currently capable of producing these good enough results. We're still working on it, and there is still a lot to do.

[hobold]

I am just constantly surprised at how that is regarded as a step forward...

Progress is always a matter of judgement. It seems you are coming from a strict automation/production point of view. To you, any trade-off that involves an increased amount of human interaction is unacceptable, right?

The people who are currently working to refine the numerics of the perturbation method necessarily see things very differently: they approach it as a research project. The potential of gaining two or more orders of magnitude higher speed is exciting, even if the method is still immature and unreliable today.

One of the awesome qualities of a research project, IMHO, is that no one really knows what the result will ultimately be. That sucks when you have to meet deadlines and specifications - but when you are free to fail or to exceed expectations, then you have a chance to make progress in a giant leap, not just the usual series of many small steps.


That's why successful researchers tend to be enthusiastic optimists: they need that kind of personality to carry them through the frustration of many failed experiments, until finally they succeed with something unexpected and new.


I don't know the future, so I cannot say if there will ever be fully automatic detection (and consequently automatic correction) of mis-rendered images. What makes me follow this development is the potential that the failure modes of the perturbation method, when finally analyzed and understood, could lead to a better understanding of the dynamics of the Mandelbrot set itself.

I could imagine that the perturbation method fails not because of reasons inherent in perturbation theory, but because a class of points in or near the Mandelbrot set exhibits special behaviour. Maybe if we can identify these points - solely for the reason of rendering nicer pictures - we end up understanding better what is going on.


But even though I don't know the future, I do know that if the researchers here were to succeed, all of the more pragmatic people would abandon the old algorithm in a heartbeat. The users would gladly accept orders of magnitude of speedup, and never care that the new algorithm did not spring into existence as a fully formed, perfect piece of art, right?

[youhn]

What hobold said!



Found something strange in Mandel Machine which I did not see before. Perhaps a bug?



The blue rectangles don't seem to fit the picture. Seen similar (smaller) things a few zoomlevels back. Param file attached. Rerendering from this file reproduces the error (did not do a restart of the program).

<EDIT>
Notice the lowest big black circle. Between the big black circle and the smaller one, there is a stripe of what looks like the same blue color. Also seen on deeper zoomlevels.
</EDIT>

[hapf]

Yes, I understand of course that GPUs don't do higher than FP64 internally (and that at greatly reduced speed compared to FP32), but as with CPUs a GPU is Turing complete and can surely do any higher precision computation the CPU can do.

I don't think there are GPU solutions for arbitrary precision with lots of bits that outperform a multi core CPU, but I'm happy to hear of the contrary if anyone can provide details.

[3dickulus]

CUDA Device count = 1

Some properties of CUDA device 0:
=================================
Name: GeForce GTX 760
Compute capability: 3.0
Number of multiprocessors: 6
Total global memory: 2147155968 bytes
Shared Mem/Block: 49152 bytes
Shared Mem Access: 8 bytes
=================================

*********************
n_digits = 156
prec_words = 12, 12
MAX_PREC_WORDS = 145
n_words = 17
numElement = 307200
*********************
Prepare data.................................
        done.
test_add ........................................
numElement = 307200, interval = 307200
numBlock = 2400, numThread = 128
interval memory layout...
*** GPU add: 0.003 sec ***
*** CPU add: 0.164 sec ***
*** The abs. of max. rel. error = 10 ^ 0 x 0 ***
*** The abs. of avg. rel. error = 10 ^ 0 x 0 ***
A sample when i = 164661
GOLD = 10 ^ 0 x 1.146514967712305809649915716387329890097697486394245497434308221497424464834325631
79364833248365700345339165485223330578732787146025929987360878945595128796
REF  = 10 ^ 0 x 1.146514967712305809649915716387329890097697486394245497434308221497424464834325631
79364833248365700345339165485223330578732787146025929987360878945595128796

test_sub ........................................
numElement = 307200, interval = 307200
numBlock = 2400, numThread = 128
interval memory layout...
*** GPU sub: 0.003 sec ***
*** CPU sub: 0.185 sec ***
*** The abs. of max. rel. error = 10 ^ 0 x 0 ***
*** The abs. of avg. rel. error = 10 ^ 0 x 0 ***
A sample when i = 90752
GOLD = 10 ^ -1 x 2.24032445053941494471490869245516024230081070034160848188327014170345318734560570
536693998741659321929492623237323066365706675874447724150862042972514377446
REF  = 10 ^ -1 x 2.24032445053941494471490869245516024230081070034160848188327014170345318734560570
536693998741659321929492623237323066365706675874447724150862042972514377446

test_mul ........................................
numElement = 307200, interval = 307200
numBlock = 2400, numThread = 128
interval memory layout...
*** GPU mul: 0.013 sec ***
*** CPU mul: 0.459 sec ***
*** The abs. of max. rel. error = 10 ^ 0 x 0 ***
*** The abs. of avg. rel. error = 10 ^ 0 x 0 ***
A sample when i = 123003
GOLD = 10 ^ -1 x 5.30056800732076570691327903160327288932904861807881356311266826572994142947323528
41976425418735331748966283710939580686946026614702874865642273292239809154
REF  = 10 ^ -1 x 5.30056800732076570691327903160327288932904861807881356311266826572994142947323528
41976425418735331748966283710939580686946026614702874865642273292239809154

test_div ........................................
numElement = 307200, interval = 307200
numBlock = 2400, numThread = 128
interval memory layout...
*** GPU div: 0.018 sec ***
*** CPU div: 0.604 sec ***
*** The abs. of max. rel. error = 10 ^ 0 x 0 ***
*** The abs. of avg. rel. error = 10 ^ 0 x 0 ***
A sample when i = 194256
GOLD = 10 ^ 0 x 1.334185451621135878465590322550729345967927280447987755070190881191672203052509390
03208758406331862064461105327812246702639904274084665067687023580592219925
REF  = 10 ^ 0 x 1.334185451621135878465590322550729345967927280447987755070190881191672203052509390
03208758406331862064461105327812246702639904274084665067687023580592219925

I've pushed garprec to 10000 digits (680 prec words) but it starts getting sketchy at those levels on my system 

[Dinkydau]

I don't think there are GPU solutions for arbitrary precision with lots of bits that outperform a multi core CPU, but I'm happy to hear of the contrary if anyone can provide details.

Bruce Dawson from fractal extreme investigated the use of GPGPU for deep zooming. The conclusion was that GPUs could be used and they would be good for low depths, but they are less efficient exactly where they are needed most: at the deeper zoom levels. Mandelbrot rendering up to the max depth for floating point precision is already so fast that it doesn't really need to be optimized more. The human efforts would be too big for almost unnoticeable extra performance. However, perturbation requires only few high-precision calculations even at high zoom levels, so maybe those GPUs aren't that bad of an idea after all!

I like the development of software that uses perturbation. For Lycium I would like to link again to the following image I rendered in 7 hours with only 8 out of 32 cores being used.
http://dinkydauset.deviantart.com/art/SSSSSurvival-of-the-fittest-Evolution-3-433586071

I think this would have taken at least 6 months to render with fractal extreme, using 32 cores. The glitches you can still spot are now 100% fixable with the latest version of mandel machine. Isn't that a step forward? I would not wait 6 months for this, so if it wasn't for perturbation, this render would not have been possible for years.

I'm also currently rendering a zoom with kalles fraktaler to such a dense and deep location that the render time is so long, this new algorithm is now literally saving me hundreds of euros in electricity. Even if it takes me a day of work to correct the glitches it's worth doing. I don't get paid hundreds of euros for a day of work normally.

[cKleinhuis]

this is going into a philosophical thread
i am so happi to release my mandelbrot tutorial, hopefully this weekend, because through the visualisations some stuff might come into the minds of the viewers, and how pertubation theory is actually working, but enough spoilering

when i talked to a physicist he was astounded that we actually did not use the pertubation theory earlier, because in physics this method is used all day long, its so to say standard procedure, because with that theory very good approximations are possible, the mandelbrot set is always a playing ground, where such theories can be examined in a deep theoretical manner, as we see we have the glitches, perhaps through some nifty tricks those gains in orders of magnitude lead to completely different applications, a very interesting field that has been opened up over a year ago

i just wonder how the method can be generalized, as far as i know it is the application of pertubation theory to a single formula ( z^2+c) but right now various other fractals beg for speed optimizations surely the mandelbrot is the mother of all, but how about e.g. hybrid forms ? how about application to the mandelbox ? (<- the mandelbox is still my favorite and in my eyes a good candidate for the holy grail and zooming deep into that mandelbox will find extraordinary results ... for sure )

keep on talkin