DX11 direct compute mandelbrot viewer

Unfortunately that doesn't help. The screen remains black when using Alt-Tab.

By pressing Ctrl-Alt-Del I was able to see that there was in fact a hidden "Mandel.exe has stopped working" message.

Do you have it working on Windows 7?

I've uploaded a new 1.6 version. It starts in window mode now.
In case the shaders fail to compile from the shader source code a message box will appear telling what is wrong.

If that happens, can you tell me what it tells ?

You still can continue by clicking the OK button, it will then make use of the precompiled shaders that I've added.

There were some warnings in the code before, I've removed those.
With this version now also the scalar version renders correctly.
The mouse handling has also been slightly improved for zooming by making it independent of the frame rate.

Good luck !

Edit: If you still get a crash than try delete or rename mandel.hlsl, this will cause it to use the precompiled shaders.
 
Last edited by a moderator:
BTW I could not find the magic registry key that activates compute shaders with the GTX on Vista.

Got it to work finally, at least after performing the following steps:
Installed the beta platform update for Vista 64 SP2 (the main update is downloadable from Windows Update, after running the .cmd script as Administrator).

Installed the August 2009 DirectX runtime redistributable.

Installed the WHQL 191.07 GeForce 200 Series drivers from Nvidia.

Searched the registry for D3D_39482904 keys and deleted them, in my case there were at:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\"D3D_39482904"=dword:00000001

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\etc..

Your DX11 feature level DX10 version download, which right now reports itself as version 1.5, then defaults to the vector version on my GTX280. Speed seems to be just a tad slower than scalar outside of black and pretty much identical on a black zoom.
 
Installed the August 2009 DirectX runtime redistributable.
I wonder if that has been the difference between it working on mine & not others Win7?
I had run that update & I think it did update some bits.
 
When extremely zooming into the mandelbrot, i get visually different images between scalar and vectorized version.

Some calculations seem not be the same then, right?
 
When extremely zooming into the mandelbrot, i get visually different images between scalar and vectorized version.

Some calculations seem not be the same then, right?

It's sometimes unavoidable though. For example, the vectorized version may have some calculations done in different order than the scalar version. In floating point math, this may lead to slightly different results. This happens in my NLM denoise too, although technically it's not vector vs scalar, but rather "cached" vs "non-cached."
 
When extremely zooming into the mandelbrot, i get visually different images between scalar and vectorized version.

Some calculations seem not be the same then, right?

Yes, the scalar version does a slightly different initialization

u = af0 + dfa*DTid.x;
v = bf0 + dfb*DTid.y;

The af0, bf0, dfa and dfb are float values, the vector version does it with doubles for better precision.

I did it this way as at first the scalar version would not compile.
Now it seems to work, so to get identical results, you need

u = (float)(a0 + da*DTid.x);
v = (float)(b0 + db*DTid.y);

As a remark, the vector version could be changed to the way the scalar version works to get it running on the HD57xx as those unfortunately don't support doubles.
 
I'm really not much of a programmer so I'm going to ask a stupid question:

What could be done so that it could be zoomed further?
More of these "iterations"?
Use double precision floating point... stuff?
 
Voxilla,

Any ideas why initializing the scalar program the same way as the vector program (i.e. using doubles) causes the rendering to break? Looks like the top line gets repeated all across the screen.

I set:
Code:
a = a0 + da*DTid.x;
b = b0 + db*DTid.y;
and it doesn't work :( I checked the program and it looks like it's properly initializing the constant buffer all the time, so it's not clear to me what's up.
 
The latest version (see below) now works both in scalar and vector with doubles.
The problem you mention seems not to occur anymore, no idea why.
 
I've added a new 1.7 version.
It can now also run on DX11 GPUs that don't support doubles like the HD 5770.

I've omitted the precompiled shaders this time, as the shader compiler DLL is included.
 
Whoa, I went to that Julia mode of the mandelbrot viewer and started to play around with holding the shift down and moving the mouse and I think the viewpoint started moving and the animation actually made me feel quite jiggy :eek: (on a 30" monitor and I think it pulled off some kind of weird optical illusion on me)
 
I've added a new 1.7 version.
It can now also run on DX11 GPUs that don't support doubles like the HD 5770.

I've omitted the precompiled shaders this time, as the shader compiler DLL is included.
Thanks for the update, I am now able to get doubles working in the scalar kernel. I think you have a minor bug with how you initialize "counter" though.
Code:
int counter = max_iterations & (~UNROLL);
Since UNROLL is 32, this is just going to mask out bit 5 meaning that setting max_iterations to 32 would give 0 for counter and setting max_iterations to 33 would give a result of 1. I think what you want is to align counter to be a multiple of UNROLL, so it should be
Code:
int counter = max_iterations & ~(UNROLL - 1);
but this only works for values of UNROLL that are powers of 2. If you want to make it more generic, use:
Code:
int counter = (max_iterations / UNROLL) * UNROLL;
 
I think you have a minor bug with how you initialize "counter" though.

Yes you're right, as the counter now is a large multiple of unroll, I didn't notice it.
Before it was with a division and I changed it as I thought the integer division might be expensive. I'll fix it later.
(could also be done before writing it in the constant buffer)
 
Back
Top