Here the locking mode can be stated, if it is different from the default locking mode: It is possible to mark such variables by the ‘NotLockable’ keyword: In a fragment, a user variable can be marked as locked by default, by adding a ‘locked’ keyword to it: The ‘BoundingSphere’ variable has a grey background, because it has keyboard focus: its value can be finetuned using the arrow keys (up/down controls step size, left/right changes value). The ‘DetailAO’ has been changed, but the changes are not executed yet (the yellow background). The ‘AntiAlias’ and ‘DetailAO’ variables are locked. The locking interface – click to enlarge. Notice, that whole parameter groups may be locked, by using the buttons at the bottom. Locked variables, which have been changes, will appear with a yellow background until the system is compiled, and the changes are executed. When a variable is locked, any changes to it will first be executed when the system is compiled (by pressing ‘build’).
Locked variables appear with a yellow padlock next to them. In Fragmentarium variables can be locked (made compile-time constant) by clicking the padlock next to them. By making most variables constant, the compile time is lowered to around ~335ms on my system. For the ‘ag’ code, the compile time is ~2000ms with no constants.
Interestingly, the ‘iterations’ variable offers no speedup – even though the compiler must be able to unroll the principal DE loop, there is no measurable improvement by doing it.įinally, the compile time is also greatly reduced when making variables constant.
MANDELBULB 3D INTERPOLATE FREE
My guess is that for complex code, the shader runs out of free registers and needs to perform calculations using a slower kind of memory storage.
MANDELBULB 3D INTERPOLATE CODE
It is not clear why this happens, but I have a guess: it seems that when the complexity is lowered between a certain treshold, the shader code execution speed increases sharply. But these speedups are not additive! Even if you make all variables constants, the framerate only increases slightly above 5.6 fps. And in fact, it turns out that combinations of other variables will amount in the same speedup. It is difficult to see from the code why these two variables should have such impact. The next speedup – from the ‘Anti-alias’ and ‘DetailAO’ variables – is more subtle. But according to this post this is – surprisingly – not very effective). Doing the calculation at compile-time gives a notable speedup of 2.4x (notice that another approach would be to calculate such frame constants in the vertex shader and pass them to the pixel shader as ‘varying’ variables. Without the constant declarations, they must be calculated from scratch for each pixel, even though they are identical for all pixels. The fractal rotation matrices are the matrices used inside the DE-loop. For instance for the ‘ag’, take a look at the following render times:Ĭonstant rotation matrices : 3.4 fps ( 2.4x)Ĭonstant rotation matrices + Anti-alias + DetailAO: 5.6 fps ( 4.0x)Īll 38 parameters (except camera): 6.1 fps ( 4.4x)
It turned out that this does have a great impact on some systems. The drawback is that changing these constant variables requires that the GLSL code is compiled again. unroll loops) and remove unused code (e.g. This way the compiler may optimize code (e.g. One way to speed up GLSL code, is by marking some variables constant at compile-time. reflections, hard shadows, and floor planes) – even if the features were turned off! After a bit of investigation, I realized that my standard raytracer had grown slower and slower, as new features had been added (e.g. Some time ago, I became aware that the raytracer in Fragmentarium was somewhat slower than both Fractal Labs and Boxplorer for similar systems – this was somewhat puzzling since the DE raycasting technique is pretty much the same.
Support for easily locking variables has been added to Fragmentarium. By making selected variables constant at compile time, some 3D fractals render more than four times faster.