View Full Version : Mandelbrot in fragment shaders?

jwatte

08-30-2002, 07:41 PM

I'm just idly wondering which implementation of the Mandelbrot fractal set renderer would run faster:

- do the actual exponentiation and test (with KIL) in a big unrolled loop

- do the successive exponentiation using a exponented-value look-up texture

I suppose the first solution would be more precise, as the exponentiation look-up texture by necessity needs to quantize the input values to 1/1024 resolution or so.

Thoughts?

Could you explain where you're getting the exponential?

The equation is z = z^2 + c (iterative). I suppose you could exponentiate each side and (since it'd be a complex exponent) do the math in terms of sin's and cosines, but would this help anything?

I think that the fastest way would be to use an unrolled loop and get as many iterations as you could packed in there. What would you be looking up in a texture that wouldn't just be a pre-computation of the part of the set the texture covers?

-- Zeno

jwatte

08-31-2002, 08:05 AM

z^2 could be in a look-up texture.

Thus, it would be a texture lookup replacing a complex multiply. Anyway, it was just an idle thought -- I'm sure someone will implement it soon enough :-)

evanGLizr

08-31-2002, 10:23 AM

Originally posted by jwatte:

z^2 could be in a look-up texture.

Thus, it would be a texture lookup replacing a complex multiply. Anyway, it was just an idle thought -- I'm sure someone will implement it soon enough :-)

The mandelbrot shader is one of the sample shaders in 3Dlabs' OpenGL 2.0 HLSL proposal (http://www.3dlabs.com/support/developer/ogl2/whitepapers/index.htm#shadinglanguage) . You can see it running on a Wildcat VP, unfortunately there are no screenshots available :/.

// Based on a renderman shader by Michael Rivero

uniform int maxIterations;

varying vec2 uv;

void main (void)

{

float tmpval;

int iter;

float tempreal, tempimag, Creal, Cimag;

float r2;

vec2 pos = fract (uv);

float real = (pos.s * 3.0 ) - 2.0;

float imag = (pos.t * 3.0 ) - 1.5;

Creal = real;

Cimag = imag;

for (iter = 0; iter < maxIterations; iter++)

{

// z = z^2 + c

tempreal = real;

tempimag = imag;

real = (tempreal * tempreal) - (tempimag * tempimag);

imag = 2 * tempreal * tempimag;

real += Creal;

imag += Cimag;

r2 = (real * real) + (imag * imag);

if (r2 >= 4)

break;

}

// Base the color on the number of iterations

vec4 color;

if (r2 >= 4)

color = vec4 (0, 0, 0, 1.0); // black

else

{

tmpval = fract ((iter / 10));

color = vec4 (tmpval, tmpval, tmpval, 1.0);

}

gl_FragColor = color;

I don't think you will get any faster by doing z^2 using a lookup texture, all the contrary, it will be quite slower.

[This message has been edited by evanGLizr (edited 08-31-2002).]

barthold

09-04-2002, 08:56 AM

We've implemented a mandelbrot shader on the Wildcat VP using OGL2's fragment shader capabilities. Here's the source.

//

// mandel.vert: Vertex shader for drawing the Mandelbrot set

//

// author: Dave Baldwin, Steve Koren

// based on a shader by Michael Rivero

//

// Copyright (c) 2002: 3Dlabs, Inc.

//

varying float lightIntensity;

varying vec3 Position;

uniform vec3 LightPosition;

const float specularContribution = 0.2;

const float diffuseContribution = (1.0 - specularContribution);

void main(void) {

vec4 pos = gl_ModelViewMatrix * gl_Vertex;

Position = vec3(gl_Vertex);

vec3 tnorm = normalize(gl_NormalMatrix * gl_Normal);

vec3 lightVec = normalize(LightPosition - vec3(pos));

vec3 reflectVec = reflect(lightVec, tnorm);

vec3 viewVec = normalize(vec3(pos));

float spec = clamp(dot(reflectVec, viewVec), 0.0, 1.0);

spec = spec * spec;

spec = spec * spec;

spec = spec * spec;

spec = spec * spec;

lightIntensity = abs(diffuseContribution * dot(lightVec, tnorm) +

specularContribution * spec);

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;

}

//

// mandel.frag: Fragment shader for drawing the Mandelbrot set

//

// author: Dave Baldwin, Steve Koren

// based on a shader by Michael Rivero

//

// Copyright (c) 2002: 3Dlabs, Inc.

//

varying vec3 Position;

varying float lightIntensity;

uniform float maxIterations;

uniform float zoom;

uniform float xCenter;

uniform float yCenter;

void main (void)

{

vec3 pos = fract(Position);

float real = ((pos.x - 0.5) * zoom) - xCenter;

float imag = ((pos.y - 0.5) * zoom) - yCenter;

float Creal = real;

float Cimag = imag;

float r2 = 0.0;

float iter;

for (iter = 0.0; iter < maxIterations && r2 < 4.0; ++iter) {

float tempreal = real;

real = (tempreal * tempreal) - (imag * imag) + Creal;

imag = 2.0 * tempreal * imag + Cimag;

r2 = (real * real) + (imag * imag);

}

// Base the color on the number of iterations

vec3 color;

if (r2 < 4.0) {

color = vec3(1.2, 0.0, 0.0);

} else {

float tmpval = fract (iter * 0.05);

vec3 color1 = vec3(0.5, 0.0, 1.5);

vec3 color2 = vec3(0.0, 1.5, 0.0);

color = mix(color1, color2, tmpval);

}

color = clamp(color * lightIntensity, 0.0, 1.0);

gl_FragColor = vec4(color, 1.0);

}

Barthold

jwatte

09-04-2002, 10:56 AM

I knew it must've been done :-)

However, regarding this quote:

"I don't think you will get any faster by doing z^2 using a lookup texture, all the contrary, it will be quite slower."

Why is that? One z^2 look-up would replace 7 fragment shading instructions (if I count right). What are the relative latencies involved?

Korval

09-04-2002, 11:21 AM

z^2 is just z*z. Hardly difficult for even register combiners (or texture_env, for that matter), let alone more powerful shaders.

evanGLizr

09-04-2002, 11:30 AM

Originally posted by jwatte:

I knew it must've been done :-)

However, regarding this quote:

Why is that? One z^2 look-up would replace 7 fragment shading instructions (if I count right). What are the relative latencies involved?

The problem is that the texture lookup is generated and consumed by the fragment shader. It's not like any "fixed pipeline" texture lookup which can be requested by an early stage of the graphics pipeline and consumed in a later stage. Unless you are able to do work in parallel with the texture lookup, this normally means quite a heavy latency (implementation dependent http://www.opengl.org/discussion_boards/ubb/wink.gif ).

Note that even if the texture data is already in the texture cache (which may not be the case for textures used as arbitrary lookup tables), you still have to request the data, the request has to flow through intermediate units to arrive to the servicer unit (texture cache) and go back to the originator in the fragment shader. Another solution would be to have a heavily pipelined fragment shader execution unit, so the texture can be requested in one stage of execution and consumed in a later stage, but I don't think you can fit so many stages between one and the other (specially without inserting bubbles to avoid RAW data hazards).

Nakoruru

09-04-2002, 09:57 PM

And this is why we need high level shader compilers now! I really do not want to have to wrap my brain around "data hazards" when all I really want to do is write a shader ^_^

stefan

09-05-2002, 12:24 AM

Astonishing to see how Shaders could look like if we had OpenGL 2 already (and astonishing too how much more advanced the wildcat hw must be compared to what the NV30 GL spec tells about the hardware). Does anyone know (or have a good guess) how loops are executed on the wildcat [Are they unrolled?] (and if somebody knows exactly just out of curiosity: What's the limit for maxIterations?)

Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.