[Jon Abbott]

Gadget Name: Mandelbrot Explorer
Version: v0.6.0.0
Date of release: 3rd July 2007
Screenshots:
 Repro44_shouldbe.png (22.26K)
Number of downloads: 13

Download:  Mandelbrotv0.6.0.0.gadget (21.53K)
Number of downloads: 101
Revision history
This Gadget randomly flies around the Mandelbrot set, zooming in on interesting points until it either gets too complex, or hits the limit a Double can handle.

Future updates
- Add the ability to do a hi-res snapshot
- Zooming through a spline path
- Use a Pixel Shader to render the image

[raskren]

Holy s***! You are a #1 Gadget developer. This is completely useless but still quite interesting from a technology perspective.

When undocked, it brings my E6600 to its knees.

[Jon Abbott]

raskren, on Jul 4 2007, 12:40 AM, said:

Holy s***! You are a #1 Gadget developer. This is completely useless but still quite interesting from a technology perspective.

When undocked, it brings my E6600 to its knees.

Yep, completely useless. Whilst playing around with the Complex maths in Spectrum Analyser, I hunted out an FFT I wrote 20 years ago. With it was a highly optimized (it checked for bifurification and other means to determine quick escape) assembler Mandelbrot generator I'd written around the same time, so I figured I'd write another but with smooth shading this time (calculating the escape velocity hadn't been thought of at the time!)

Doesn't surprise me it grinds your PC to a halt! I've not optimized it much, in fact the only optimization I've done is to process two pixels at once to make better use of the CPU/FPU. Ideally I need to recode the iteration loop into assembler and use SSE2/SSE depending upon the complexity of the maths.

[Bryant]

You should probably GPU-accelerate it

I know nvidia and ATI both have APIs for running complex math on their GPUs, though I'm not sure how that would work in .net

[KPK]

As a fan (and creator, see: KPK's fractals ) of fractal art I love it

KPK

[Jon Abbott]

Bryant, on Jul 4 2007, 11:53 PM, said:

You should probably GPU-accelerate it

I know nvidia and ATI both have APIs for running complex math on their GPUs, though I'm not sure how that would work in .net

I did look around at generic API's, EcoLib looked promising, but there's no documentation and I'm guessing it's not free.

If you anyone knows of a free API that works on all GPU's, let me know. I'm always up for a challenge.

[Jon Abbott]

Bryant, on Jul 4 2007, 11:53 PM, said:

You should probably GPU-accelerate it

I know nvidia and ATI both have APIs for running complex math on their GPUs, though I'm not sure how that would work in .net

I recoded it using Microsoft's GPGPU library., computing all pixels in parallel.... And god is it slow, mainly due to having to fully iterate every pixel to the maximum iteration count. Ironically it also uses more CPU cycles than computing on the CPU, because of all the setup and extraction code needed to get the values in/out of the GPU. Mind you, Microsoft didn't have iteration in mind when they wrote their library, so it's very inefficient.

Ideally, the iteration loop needs to be hard coded as a pixel shader to get massive improvements, or I need a generic library that supports breakout when looping and const values based on the x,y within the parallel array.

Interesting problem though, computing an iteration in parallel.

[Jon Abbott]

Having spent a few days learning Direct3D programming, I've knocked up a Pixel Shader3 demo in XNA as an EXE. You'll need an XB360 controller if you want to move around.

Speed wise, at 512x512 on my X1900 I'm getting a solid 60fps. Even 1024 iterations on every pixel gets over 12fps.

Before I shove this in the Gadget, I need to resolve some issues. Getting the total iteration count and interesting C values out from the Pixel Shader is going to be a challenge. They're used to automatically adjust the iteration level based on the screen complexity and figuring out which points to aim for. The problem is, Constant registers (which can easily be read in managed code) can't be modified by the Pixel Shader - so there's no easy way to get values out, short of putting them into a texture. Which is damn complicated from what I can tell as it will have to do several passes to reduce it down to a 1x1 texture. To be truthful, I haven't investigated this much so I could be talking rubbish.

Another major issue is precision. The compiler is converting the Doubles to Singles, so it's very restricted on how far you can zoom in, and it would appear that ATI's only use 24bits of that anyway, so the best precision I can get is 5E-5 (the Gadget is currently 1E-15). You also can't pass a Double from XNA/MDX to a Pixel Shader, you're restricted to Singles, although I've worked around this by converting to 64bit integers and passing the low and high 32bits separately.

I think ultimately, I'll have to drop all floating point and resort to 64bit maths, which will seriously slow it down due to the amount of computation involved - precision will improve three fold though. The last time I had to implement that was when doing 3d maths in machine code on the 6502 25 years ago, before 16bit registers existed!

Controls:

Left Thumbwheel - Move
A - Zoom in
B - Zoom out
X - Decrease iteration count (min is 48)
Y - Increase iteration count (max is 1024)

When you zoom in/out, it automatically adjusts the iteration count to a best guess.

Attached File(s)

•  Mandebrot.zip (8.2K)
  Number of downloads: 14

[AlphaAlien]

very nicely done I'm impressed

[Jon Abbott]

I've just about given up on enhancing the GPU version, having spent nearly a week fighting with the compiler, to stop it "optimizing" (ie removing important code)! Having said that it's all coded and would work, if the compiler wasn't trashing my hard work! (The compiler command-line switch to disable optimizations doesn't seem to work in the current DirectX SDK.)

I know it can be done, as I've read several papers (1, 2, 3) on the subject where they've successfully implemented Double and Quad Floats in Cg (I'm using HLSL). I've also read that NVidia's upcoming 9800 will natively support IEEE Doubles - which will be interesting as it will require an update to DirectX 10 to support them. I'd guess ATI will go this route as well, as many developers are now nagging them for it to make HDR etc. more accurate.

Ironically, Doubles are supported by Pixel Shader compilers (MS's compiler stated it emulates if it's not available in hardware). Unfortunately, they don't emulate and currently Managed DirectX doesn't support passing Doubles to a PS.

There's another reason for not going down the GPU route. If the GPU is tied up doing long winded maths (12 instructions for Singles, ~100 for Doubles per iteration), it can't service the OS. It literally locks the GUI of the OS until it's finished rendering the texture. Okay for scientific research, but not a Gadget on Vista!

I've learnt how to code Pixel Shaders, so it was interesting none-the-less.