Luna-Canis

I’m working on binding non-varying variables to temporary node parameters. I’m noticing a few design flaws:

There is no difference between Global and Parameter symbol types. Don’t know why I was trying to distinguish them in the first place. Well, probably because of the Production Rendering book. I should probably get rid of the Global type.

Also, the way I’m handling the binding/varying step is a bit forced. The CVEX api has a much better way of determining which parameters to bind to, which will be written, which can be discarded since they’re not being used. Here is a rough listing of the API

• Declare a run context
• Call addInput for all the inputs you intend on writing to. You specify whether they will be varying or not here.
• Load the vex function. At this time, the run context will define which output variables will be written to, if any. It also determines which inputs are active.
• The calling function binds all active input and output variables. It also probably should check them for varyingness.
• Run the code - get results.

I’m a bit concerned about changing the run context, since it seems to be working, but this seems to be a good time to clean up the api before I go further.

First problem: The varying/non-varying analysis takes place in the compiling step, now it will have to take place after it reads in the vex code. This may be easier with assembly commands, since there is no recursion. We simply tag the inputs varying, then propate the varyingness down to the temp variables. No inputs will write to any other inputs, so there can be no variable conflicts.

We will have to explicitly declare output variables, but that’s fine. It would create a less ambiguous grammar. Also, the vex optimizer will optimize out blocks of code if they’re not being written to. I don’t want to do that. It might cause another level of complexity that I really don’t want to deal with. I think that doing the varying propagation at the assembly language level can be done reasonably within the current architecture.

Crap, I’ll have to go back and re-test all the old shader test code. Still, this will improve the grammar.

Instead of changing, (and breaking) the existing grammar, I’m just going to add new features, deprecate the old features, then take them out sometime later. Specifically, I’m getting rid of the ‘Global’ keyword. Replacing it with

{Input,Output,InputOutput} type name ( = initExpression) ;

As previously mentioned, no varyingness will be specified in the shader grammar. This will be determined after the assembly file is read in, and the inputs are declared. InitExpression can’t contain variables.

---

I have the new Input Output implemented into the grammar. It LOOKS a lot nicer, I really didn’t like the old Global declarations. Another plus is that here, I can specify for a variable to be a node parameter. So the shaders can start to have user defined parameters.Next step is to have the Inputs/Outputs explicitly declared. Then have the varyingness propagated through to the entire shader at the assembly level.

---

I’m having to re-learn the relationship between a shader, and a shader instance. The shader holds the instructions, but the shader instance holds the cpu counter, the arrays of data, variables, etc.Another overlooked issue, since I’m doing variable and flow analysis on assembly instructions, I need to find a way for assembly instructions to automatically state which variables are being read, and which are being written to. Once I have that, I can do the varyingness propagation. Probably also fold out unused parts of a shader, depending on what inputs are defined/linked.For the assembly instructions, I’ve followed a convention where input operands are last, and the operand to be written to is first. I imagine that I will have to allow for more complicated functions which can potentially write out to more than one operand. By default, I’ll have the InstInfo struct default to each function writing to arg[0]. Some of the i/o functions, such as print, don’t write to any variable. They write to stdout/stderr. So I’ll have to allow for this info to be modifiable. Changing all of TokenInstPair might not be the way to go. Maybe create a TokenInstTuple, that takes another object (a bit-field ??) that specifies the output parameters.

I got a bitfield defined, and its part of the InstTable object. Looking back at the assembly opcode format, I already have the info as to the number of arguments per opcode, and their argument types. Using that with the output bitfield, I should be able to extract a data-flow.

The assembly code arguments are defined in the dumpAsm() method in smd::Funct, but they should be properly defined in the InstTable when the smd commands are generated.

Funny, another thing I seem to have left out of the symbol spec is having parameters defined as input, output, or both. I’ll have to extend the symbol file format to include this. Since the varying/non-varying modifier will no longer be used for the symbol file format, I can use this field for specifying input/output/both, or neither for parameters. I can use {iobn} for {Input,Output, Input & Output, Neither} respectively.

The existing symbol descriptor is: [DFISO][0-9][CPTG][cv]. [Double,Float,Int,String,Other], [Constant,Parameter,Temporary,Global],[const,varying].

The new symbol descriptor (should be) [DFISO][0-9][CPT][uh][iobn]. DFISO is the same, CPT is the same, just drop the Global, [uh] is [User,Hidden] is for parameters to be exposed as user parameters, [iobn] is [Input,Output,Both,Neither]. The new descriptor is 5 characters instead of 4.

Having some linking issues. In the CVEX context, we provide the input arrays of data, which I believe matches my current API which is good. For exported variables, the client also allocates the plane data.

There is an unclear relationship between the Grid, the ShaderInstance, and the RunContext. I think there might be multiple instances of Planes between the Grid and the Shader Instance. The logic in the symbol bind stage is all over the place.

The Grid object seems to be something that’s really not needed for a pure simd implementation. I was trying to account for the grid in a reyes architecture, but not only is this not needed for running simd across pixels, but the data it is supposed to represent gets defined and allocated by the client to begin with. I should take it out.

I got the first shader example working. The varyingness propagation works well. Hoping that it also works with the for/while loops as well. Going through the rest of the shader examples to be certain that they work as well. API is much cleaner.

All the shader examples seem to be working. If I can get the while/for stuff working, the simd api will have taken some great steps forward.