Luna-Canis

Been working on The Mummy III, haven’t worked on Bwain in a while. I chopped up a copy of this, to give to Cecil. But now, its back to fleshing out the shading language. For loops were done, onto while loops…..

Crap, I forgot… I was in the middle of implementing break/continue. Should get that working first…. The big problem is finding the nearest enclosing while/for/switch statement. I can either do a recursive search from the base statement to a given leaf to find its enclosing path, then trace up. OR, have all commands keep a pointer to their parent. We’ll do the latter. That will handle 95% of the cases. I can come up with examples that will break it, but just want to get this started.

The grammar and the script commands are implemented for break and continue. Break seems easiest to start with. For the shading language, I just need to disable the cpu thread when break is executed.

While debugging ‘break’, I’ve been thinking about having a more general simd debugging environment. Something that would allow for stepping and breaking assembly instructions, display the thead activation state, examine variables, etc.

What would also be nice is to clean up the simd execution api, possibly to have it more similar to the CVEX context from Sidefx.

The variable holding the test condition for the loop is non-varying if the expression defining it is non-varying. This works well, except for when I introduce continue/break statements, that themselves, are functions of varying expressions.

To fix this properly, I would have to detect whether there exist control flow statements (such as break/continue), determine their granularity (const/varying), then adjust the boolean test variable. Caveat, assigning a const expression to a varying variable. Seeing as how this is the only example where this is necessary, I could provide this functionality in the loop-while instruction.

The more difficult issue will be to propagate up const/varying-ness through Cmd classes. Since they’re recursive, this should not be too much of an issue….. famous last words….

Having the commands determine their execution granularity wasn’t as hard as I thought… The next part is to have a simd ‘while’ instruction that takes a non-varying boolean, but executes with varying granularity. We need a const boolean for the loop test condition, and a varying boolean to count the break deactivation counts. This is so we do the proper amount of thread activation when exiting the loop.

Another caveat is that there could be multiple break/continue statements with different control granularity. So we have to keep track of each break/control statement, along with its varyingness, and have them update the control boolean appropriately. All 4 combinations of varyingness are possible:

• varying loop test, varying break/continue
• varying loop test, non-varying break/continue
• non-varying loop test, varying break/continue
• non-varying loop test, non-varying break/continue

Have to be able to handle all these cases…. ugh….. Only the varying control statement need a boolean variable. The const control statements can be emulated with a jmp command.

I got the non-varying loop, varying break to work. Now I’m combining that with the non-varying break. If we have ONE varying break, then all breaks are varying. If we have no varying breaks, then all breaks can be implemented with a single ‘jmp’ command.

So if we have a varying ‘if’ statement containing a break/continue, all if statements after that need to be promoted somehow to be varying, since they will have a varying subset of active threads executing them.

Need to find a normal way to promoted ‘if’ statements to varying.

To assign a constant value to a varying variable, we can execute it normally, which will only fill in the first value. Then have a templated assembly instruction which will copy the first value to the rest of the values. Then we need to be able to recurse through instructions and force them to be varying. That would include ‘if’, ‘for’ and others.

Crud, I need to be able to determine a relative dfs ordering for all control statements so that I know which ones precede others. The way to do that would be to have a single list of break/continue statements instead of keeping them seperate.

This varying/non-varying promotion is turning out to be a huge undertaking. Not sure if I want to be implementing the entire thing right now. I have to be able to promote all instructions to varying. That means that all expressions need to be able to assign constant values to varying ones, not just the ‘if’ example. So that means that I would have to do another pass, through all expressions, check to see if a non-varying amount is being assigned to a varying one, then do the expansion if necessary. Lots of debugging….

To be honest, this would be the most appropriate time to be implementing this, while I’ve got the code in my head. But a more immediate goal would be to get the shading language in a usable form, creating artwork with it. This compiler stuff can wait until I have the time to implement it. More important things need attention at the moment.

For now, I will stick to implementing the 4 different combinations of for loop control combinations, I wont worry about combining varying and non-varying code. I hope it doesn’t cause some bug that bites me in the ass. But I’m certain I can make code explicitly designed with those limitations in mind.

The only combination that didn’t work is varying test with non-varying break statement. But as previously stated, this would only work if we could come up with a way to promote const commands and expressions to varying ones. This is possible, but I’ve got bigger fish to fry. For the moment, if I detect the case, I’ll give a compiler warning.

Have a set of varying and non-varying break/continue statements working with for loops. Going to go over the basic algorithm for reference.

• non-varying test - non-varying control
• The loop is handled the same, the break/continue statements are handled as jmp commands.
• non-varying test - varying control
• For a break statement, we use do_while_br instead of do_while. do_while_br takes in two boolean variables, one for the loop (non-varying) and one for the break (varying). It uses the latter boolean for re-enabling the threads when the loop finishes.
• For a continue statement, we just do a regular do_while, and a break_var for the continue statement. We re-enable the disabled threads with a continue_enable to re-enable the disabled threads at the bottom of the loop.
• varying test - varying control
• The break and continue statements are handled the same as the non-varying test case. Boolean variables keep track of which threads were disabled.
• varying test - non-varying control
• This is not yet implemented. To do this properly, we would have to have a mechanism for promoting commands and expressions from non-varying to varying. I started looking into this, its definitely possible with the current architecture, just going on the back burner for now. I’m certain I can model code around the issue. It would be nice to have ‘unbreakable’ code though.

Going to do ‘while’ statements. This is a subset of the ‘for’ loop funtionality, so it shouldn’t take long…

Got ‘while’ working with break/continue….

The first stab at providing a base level of functionality for the shading language has been finished. I should have a shot of patron.

The first immediate goal is to emulate Ultrafractal. So to that end, a missing GUI component I need is to have the gradient editor working. I have lut which is a subclass of the curve editor, but its extremely unstable. I think recoding from scratch for this case might be the base move.

Some missing language (not necessarily shading language, just more general parsing) functionality is to have the grammar parse multiple functions, in addition to the shader code. This would allow for a more programmable operator. The scripting language could be used to define GUI elements, defaults, callbacks, etc. Also need a non-hacked way to define constants. Not just constants for the shading language, but constants for scripting as well. Maybe for now, they can be defined at compile time.

The next step, definitely, will have to be the gradient operator. Back to openGL.

Started the emulation of ultrafractal .The first step will be creating a color lut operator like Ultrafractals Gradient operator.

Its easy to reverse engineer all the parameters from the text file description they use.

• Smooth or linear interpolation
• Global offset for all the color keyframes.
• Numnodes - number of keyframes
• color - a decimal number which when converted to hex gives 8 bits per color
• index - location of the keyframe

There seem to be 400 possible positions on a gradient. I’ll be using float values, but this will be useful for converting from their text files. The global position has zero at the center and goes from -200 to 200. The index of the points gets updated as the global offset is shifted.

Ultrafractal caches the escape time calculations, so that the user can experiment with layers and colors relatively quickly. For now, the operator will just have to take one plane, and do the lookup.