Hi.

I was wondering: What would it take to have a special hardware fractal
generator (HFG)
that could calculate, say, the Mandelbrot set, to extremely deep zoom
levels (say,
4096 bits of precision (!))? How much of an advantage would it offer
over a regular
computer?
(snip)

Is this possible?

I guess what you need is an FPGA to make the prototype, and then go
with it to convince some hardware manufacturer so he implements the
thing in an ASIC (fpgas are not that fast). If I was you, I would just
do it in software, it's free, takes one day to implement, and you
don't have to mess one year of hardware headaches. If you are in a
hurry, just borrow some PCs, rendering speed will scale linearly with
the amount of friends you have. I'm serious, go for software. By the
way, I realized that with the amount of pixels your movie will have,
it will take around one week to the fastest disk on the market to
write the data out, whatever the rendering speed is Funny
(although you can parallelize both works of course). However I still
don't see what's the interest of going deeper and deeper, you will not
make more beautiful images like that (these horrible videos are the
proof of it:http://www.fractal-animation.net/ufvp.html, poor guy) ,
unless you want a kind of Guinness record or something.Where are you
from?

On Sat, 5 Apr 2008 15:39:33 -0700 (PDT), mike3 <mike4...@yahoo.com
wrote:



Hi.

I was wondering: What would it take to have a special hardware fractal
generator (HFG)
that could calculate, say, the Mandelbrot set, to extremely deep zoom
levels (say,
4096 bits of precision (!))? How much of an advantage would it offer
over a regular
computer?
(snip)

Is this possible?

Judging from the improved speeds of assembly coded Mandelbrot
algorithms and edge tracing routines, a dedicated hardware embodiment
should go whizzing at impressive speeds.

Two similar constructs come to mind.  The Feistel cipher is often
depicted as a ladder of calculations which are only slightly similar
to the Mandelbrot iterates but provides a model for the hardware
embodiment.http://en.wikipedia.org/wiki/Feistel_cipher#Construction_Details

Another similar construct is the Linear Predictive Coding chip first
used in the Texas Instruments toy, Speak and Spell.http://en.wikipedia.org/wiki/Speak_&_Spell_(game)
"The Speak & Spell used the first single-chip voice synthesizer, the
TI TMC0280, which utilized a 10th-order linear predictive coding (LPC)
model and the electronic DSP logic.[2]."

The Speak and Spell chips produced the effect of a ladder of
difference filters in order to simulate the human voice box. Depending
on your interest, a search for the current expressions of these
technologies should illuminate the basic approach for a dedicated
M-brot generator. My guess is that standard DSP IC's would suffice for
the building blocks.

On Apr 6, 6:56 am, John Bailey <john_bai...@rochester.rr.com> wrote:





On Sat, 5 Apr 2008 15:39:33 -0700 (PDT), mike3 <mike4...@yahoo.com
wrote:

Hi.

I was wondering: What would it take to have a special hardware fractal
generator (HFG)
that could calculate, say, the Mandelbrot set, to extremely deep zoom
levels (say,
4096 bits of precision (!))? How much of an advantage would it offer
over a regular
computer?
(snip)

Is this possible?

Judging from the improved speeds of assembly coded Mandelbrot
algorithms and edge tracing routines, a dedicated hardware embodiment
should go whizzing at impressive speeds.

Two similar constructs come to mind.  The Feistel cipher is often
depicted as a ladder of calculations which are only slightly similar
to the Mandelbrot iterates but provides a model for the hardware
embodiment.http://en.wikipedia.org/wiki/Feistel_cipher#Construction_Details

Another similar construct is the Linear Predictive Coding chip first
used in the Texas Instruments toy, Speak and Spell.http://en.wikipedia.org/wiki/Speak_&_Spell_(game)
"The Speak & Spell used the first single-chip voice synthesizer, the
TI TMC0280, which utilized a 10th-order linear predictive coding (LPC)
model and the electronic DSP logic.[2]."

The Speak and Spell chips produced the effect of a ladder of
difference filters in order to simulate the human voice box. Depending
on your interest, a search for the current expressions of these
technologies should illuminate the basic approach for a dedicated
M-brot generator. My guess is that standard DSP IC's would suffice for
the building blocks.

Hmm. It looks though like this would be a complicated circuit.

Here's a diagram for a 4-by-4 bit -> 8-bit multiplier I scrounged
up:

http://www.edacafe.com/books/ASIC/Book/CH02/CH02-38.gif

Now imagine 4096-by-4096 bits -> 8192 bits. Yow-wee. That's
like 1048576 times more complex. Plus you need that
extra stuff to handle the floating point bits (exponent field, sign.).
And you need 3 of these multiplier circuits since it's a complex
multiplication (squaring). Plus adder/subtractor circuits as well,
although those are much less complicated than the multiplier.

Hi.

I was wondering: What would it take to have a special hardware fractal
generator (HFG)
that could calculate, say, the Mandelbrot set, to extremely deep zoom
levels (say,
4096 bits of precision (!))? How much of an advantage would it offer
over a regular
computer?

Hi Mike,

Hi.

I was wondering: What would it take to have a special hardware fractal
generator (HFG)
that could calculate, say, the Mandelbrot set, to extremely deep zoom
levels (say,
4096 bits of precision (!))? How much of an advantage would it offer
over a regular
computer?

"16384x8192x30x60x30x1.5 = 1.08 trillion minutes"

You are forgetting antialiasing and motion blur... "no no no, please
don't render such an epic movie without motion blur, or you will go to
hell". If you do 3x3x24 supersampling for example (as I used once herehttp://www.youtube.com/watch?v=fLrSapMYUlI- it was back in 2002 I
think), you get 2348 trillion minutes (more than4 trillion years), not
bad!

Now, speaking only on how I would do it (so I might not apply to your
project), I would try some more clever coloring algorithm than the old
escape time one (so 80s), imho it's a pity to render such a long movie
with "that" algorithm. Say you do some orbit traps, or distance
estimation... put few log() or sin() here and there... and your 1.5
minutes/pixel estimation goes to 20. Oh yes, by the way, how did you
do the 1.5 min/pixel experiment? Did you implement your own bignum
library?

I still think that since doing it in HW will just speed up by a
constant factor (say x100, what I feel is too optimistic) you don't
really solve the problem. You need to find something clever to compute
the movie in sublinear time... I don't know what or how, exploiting
some kind of frame to frame coherence perhaps (ala Xaos), dunno. I
would personally rather spend the budget to convince people to put
your program as wallpaper as they do with the "electric sheep", or ask
google to give a hand.

Indeed as ahkna says, today with pixel shaders 4 and integer textures
and instructions support, one can implement "arbitrary" precision
arithmetic. I would definitively give it a try during few weeks to say
if its an interesting alternative, I personally see it much more
attractive than going the HW way, if its fast enough of course.

Sorry for writing so many random comments. Keep us updated

Now, speaking only on how I would do it (so I might not apply to your
project), I would try some more clever coloring algorithm than the old
escape time one (so 80s), imho it's a pity to render such a long movie
with "that" algorithm. Say you do some orbit traps, or distance
estimation... put few log() or sin() here and there... and your 1.5
minutes/pixel estimation goes to 20. Oh yes, by the way, how did you
do the 1.5 min/pixel experiment? Did you implement your own bignum
library?

I would rather use escape time, since it is so simple, and like you
said, putting a clever coloring algorithm in there would only serve to
punish the render time considerably. I say go for simplicity
and maximum speed. I've also not been impressed myself with the
lack of fine detail revealed by orbit traps and distance estimator,
and the "blobby" look I seem to get with them, although maybe
my implementation is crap

Although perhaps I would use a smoothed
iteration count to avoid banding. That only requires one log
computation, at the end of the iteration, and it's on a real
number.

If one is serious about getting this film to screen, then (1) is
out of the question, and therefore one must go for (2) or (3).
A billion dollars is 4 times the budget of Titanic, the most expensive
movie ever produced. The ASIC-based custom HW may still
run to several tens of millions, which is comparable to most
big budget Hollywood films. Getting enough sponsors to get
together a budget like that for an independent "studio" will be
difficult. Especially for a film as "niche" as this one, since I'm
not sure how many people in the world would want to come and
spend 30 minutes of their time watching a cheesy zoom-through
of the Mandelbrot set, an object from obscure mathematics
(Although I would, if I were the one producing this. And even if
I wasn't. )

Now, speaking only on how I would do it (so I might not apply to your
project), I would try some more clever coloring algorithm than the old
escape time one (so 80s), imho it's a pity to render such a long movie
with "that" algorithm. Say you do some orbit traps, or distance
estimation... put few log() or sin() here and there... and your 1.5
minutes/pixel estimation goes to 20. Oh yes, by the way, how did you
do the 1.5 min/pixel experiment? Did you implement your own bignum
library?

I would rather use escape time, since it is so simple, and like you
said, putting a clever coloring algorithm in there would only serve to
punish the render time considerably. I say go for simplicity
and maximum speed. I've also not been impressed myself with the
lack of fine detail revealed by orbit traps and distance estimator,
and the "blobby" look I seem to get with them, although maybe
my implementation is crap :)

these ones are not astonishing, but quite watchable work on orbit
traps (even at very small zoom levels)

http://www.fractal-recursions.com/files/anim/anim.html

Although perhaps I would use a smoothed
iteration count to avoid banding. That only requires one log
computation, at the end of the iteration, and it's on a real
number.

If one is serious about getting this film to screen, then (1) is
out of the question, and therefore one must go for (2) or (3).
A billion dollars is 4 times the budget of Titanic, the most expensive
movie ever produced. The ASIC-based custom HW may still
run to several tens of millions, which is comparable to most
big budget Hollywood films. Getting enough sponsors to get
together a budget like that for an independent "studio" will be
difficult. Especially for a film as "niche" as this one, since I'm
not sure how many people in the world would want to come and
spend 30 minutes of their time watching a cheesy zoom-through
of the Mandelbrot set, an object from obscure mathematics
(Although I would, if I were the one producing this. And even if
I wasn't. )

hehe, I would definitively not go to cinema for a log2(log())
rendering of the Mandelbrot set (btw you need two logs for the
smoothed iteration count since it's based on the lof of the HD
potential).

Still, to my eyes it's 'crazy' to spend a multimillion dollar budget
to render with escape time algorithm, I really fail to see the point.

Unless you really want to stress your spectators on the zooming idea
(so they understand the idea of inifinity perhaps?), but you didn't
explain us yet why you want to zoom so deep, I'm really curious
(although the fact you speak in dollars and not in eurosa gives me an
clue )

Good luck anyway, and if the projects is not too secret and you can
drop a line from time to time here, please do it!

On Sat, 5 Apr 2008 15:39:33 -0700 (PDT), mike3 <mike4...@yahoo.com
wrote:



Hi.

I was wondering: What would it take to have a special hardware fractal
generator (HFG)
that could calculate, say, the Mandelbrot set, to extremely deep zoom
levels (say,
4096 bits of precision (!))? How much of an advantage would it offer
over a regular
computer?
(snip)

Is this possible?

Judging from the improved speeds of assembly coded Mandelbrot
algorithms and edge tracing routines, a dedicated hardware embodiment
should go whizzing at impressive speeds.

Two similar constructs come to mind. The Feistel cipher is often
depicted as a ladder of calculations which are only slightly similar
to the Mandelbrot iterates but provides a model for the hardware
embodiment.http://en.wikipedia.org/wiki/Feistel_cipher#Construction_Details

Another similar construct is the Linear Predictive Coding chip first
used in the Texas Instruments toy, Speak and Spell.http://en.wikipedia.org/wiki/Speak_&_Spell_(game)
"The Speak & Spell used the first single-chip voice synthesizer, the
TI TMC0280, which utilized a 10th-order linear predictive coding (LPC)
model and the electronic DSP logic.[2]."

The Speak and Spell chips produced the effect of a ladder of
difference filters in order to simulate the human voice box. Depending
on your interest, a search for the current expressions of these
technologies should illuminate the basic approach for a dedicated
M-brot generator. My guess is that standard DSP IC's would suffice for
the building blocks.

I guess what you need is an FPGA to make the prototype, and then go
with it to convince some hardware manufacturer so he implements the
thing in an ASIC (fpgas are not that fast). If I was you, I would just
do it in software, it's free, takes one day to implement, and you
don't have to mess one year of hardware headaches. If you are in a
hurry, just borrow some PCs, rendering speed will scale linearly with
the amount of friends you have. I'm serious, go for software. By the
way, I realized that with the amount of pixels your movie will have,
it will take around one week to the fastest disk on the market to
write the data out, whatever the rendering speed is Funny
(although you can parallelize both works of course). However I still
don't see what's the interest of going deeper and deeper, you will not
make more beautiful images like that (these horrible videos are the
proof of it:http://www.fractal-animation.net/ufvp.html, poor guy) ,
unless you want a kind of Guinness record or something.Where are you
from?

On Apr 6, 6:11 pm, Inigo Quilez <caos.s...@lycos.com> wrote:



I guess what you need is an FPGA to make the prototype, and then go
with it to convince some hardware manufacturer so he implements the
thing in an ASIC (fpgas are not that fast). If I was you, I would just
do it in software, it's free, takes one day to implement, and you
don't have to mess one year of hardware headaches. If you are in a
hurry, just borrow some PCs, rendering speed will scale linearly with
the amount of friends you have. I'm serious, go for software. By the
way, I realized that with the amount of pixels your movie will have,
it will take around one week to the fastest disk on the market to
write the data out, whatever the rendering speed is Funny
(although you can parallelize both works of course). However I still
don't see what's the interest of going deeper and deeper, you will not
make more beautiful images like that (these horrible videos are the
proof of it:http://www.fractal-animation.net/ufvp.html, poor guy) ,
unless you want a kind of Guinness record or something.Where are you
from?

On those deep zooms though they went into the "easy" real-axis
spike area, which tends to have lower iteration counts. I would
target something else, like the Candelabra valley area (at
~ -0.5622 + 0.6428i), or down in the Seahorse or Elephant valleys.
Areas with more complexity. I suppose the manufacturer
could be "convinced" with enough money. :)

Also, hardware will be necessary. On my computer, 8,000,000
iterations of a single pixel at 10^1500 depth takes around 35
minutes, using 1 CPU core. With the quad core that gives
1 pixel every 9 minutes effectively.

Using that figure, and assuming we actually average 1/6 this
time over the whole movie (since it's not all going to be rendered
at 10^1500 depth and not all at 8,000,000 iterations certainly not
for every pixel!), that is, 1 pixel every 1.5 minutes, then to
render it on my machine alone would take 16384x8192x30x60x30x1.5 =
1.08 trillion minutes to render the whole film, or 21 million years.
Holy cow.

But of course we weren't planning on using just one computer.
Naah. Even with 1000 computers we're still talking 21 millenia.
Even a million computers takes us to 21 years. That's way too
much. Ten million computers or more is what we'd need. That's
several BILLION dollars worth of computing equipment. I'd
say around $7 billion using commodity hardware. Nah, that's too
much for such a cheesy movie.

So the question then is, how much speedup would an ASIC offer?
Would 100x the power of a regular CPU be like it? If so, then
we'd need only 100,000 ASICs to get the job done. If one can
get them at $3000 a piece, we're down to $300,000,000 budget.
Is that a good estimate?

Failing that, we could always settle for a lower-resolution movie,
and abandon IMAX, or go for a lower zoom depth. If we did
the film at, say, 4096x2048 resolution (1/16 what we had before),
we'd need under a million commodity computers, and only
6,250 ASICs, which would @ $3000/pc. give $18,750,000
budget. Not as bad.

We could also quarter the exponent in the zoom, settling for
10^375 final magnification. This would still give us around
1.6x per second (i.e. the zoom factor is multiplied by 1.6 every
second, not 1.6 is added every second.). Since multiplication
grows at O(n^2), this means we cut our time by 16. The
required iteration count goes down too. I'll say down
by half just to be pessimistic. We're then down to 1/32 of
the time. That would give us around $9.4 million on ASICs,
$200 million on commodity.

Of course, all that up there was more or less entirely
guesstimated, so it could be all (and likely IS all) way off.
But it makes me think that ASICs are in fact much cheaper
than commodity hardware for the production of this film of films...