Nik, I will look into it. Can you give me a short kernel and the code that calls it -- I will try to reproduce the problem.

*Originally posted by:*Hi! After downloading and installing the 1.01 version of Brook+ some of my previously running code seems to be broken, i.e. kernels return numbers that are wrong. I found that while ... float tempsum = 0.0f; tempsum = tempsum + lookup[index].x * (parameters**nberger***.x*parameters*.x+parameters*.y*parameters*.y); ... will always leave tempsum zero (irrespective of input parameters), splitting the expression into ... float tempsum = 0.0f; float parpart; parpart = (parameters*.x*parameters*.x+parameters*.y*parameters*.y); tempsum = tempsum + lookup[index].x * parpart; ... does deliver meaningful results. This might be linked to the fact that I get a lot of warnings from Brook+ which I do not really understand (see below). Any ideas? Thanks Nik 1>Performing Custom Build Step 1>WARNING: ASSERT(GetResultSymbol().IsValid() + mDataTypeValue.IsValid() >= 1) failed 1>While processing :471 1>In compiler at AST:elayedLookup::ResolveSymbols()[astdelayedlookup.cpp:139] 1> *mName = __indexof_sum 1>Message: unknown symbol 1>ERROR: ASSERT(errorCount==0) failed 1>While processing :482 1>In compiler at AST::Root::CompileShaderToStream()[astroot.cpp:157] 1> errorCount = 1 1>Message: Unknown Symbols exist 1>Aborting...- Ok, here is the small kernel that reproduces the problem (here "result" is always 1.0, irrespective of input):

kernel void problem(float input<>, float2 lookup[][], float2 parameters[], out float result<>){

float j = 0.0f;

float2 index;

index.x = input;

index.y = 0; result=lookup[index].x*(parameters[j].x*parameters[j].x+parameters[j].y*parameters[j].y);

}

The "input" stream is just an index, running from 0 to 8192, "lookup" is a large lookup table with 8192 elements in one dimension and three elements in the other one. Parameters has just 2 elements. In this simple example, the gathers coud of course be replaced by constants or stream access, in my actual calculation this is however not the case. Both the kernel below (using an intermediate variable) and replacing parameters with a constant solve the problem.

kernel void problem(float input<>, float2 lookup[][], float2 parameters[], out float result<>){

float j = 0.0f;

float2 index;

float temp;

index.x = input;

index.y = 0;

temp = (parameters[j].x*parameters[j].x+parameters[j].y*parameters[j].y);

result = lookup[index].x * temp;

}- Just to add, the following statement in a kernel also produces nonsense:

tempsum = tempsum + 2.0f*(parameters[k].x * parameters[j].x * lookup[index].x

+ parameters[k].y * parameters[j].y * lookup[index].x

+ parameters[k].x * parameters[j].y * lookup[index].y

- parameters[k].y * parameters[j].x * lookup[index].y);

while the equivalent

parpart = 2.0f * parameters[k].x * parameters[j].x * lookup[index].x;

tempsum = tempsum + parpart;

parpart = 2.0f * parameters[k].y * parameters[j].y * lookup[index].x;

tempsum = tempsum + parpart;

parpart = 2.0f * parameters[k].x * parameters[j].y * lookup[index].y;

tempsum = tempsum + parpart;

parpart = 2.0f *parameters[k].y * parameters[j].x * lookup[index].y;

tempsum = tempsum - parpart;

works all right. Seems to me something goes wrong with long statements involving gather. Very unpleasant, as I cannot trust most of my previously working code...

- Thanks for looking into it - could you be a bit more specific on what works and what doesn't? My code is full of long statements involving gather and it would be a great help to have some criterion as to whether they are safe or not without running a complete program.

Thanks

NikNik,

As we start investigating this bug, we will find the issue that is responsible for failure, at which point I will be able to tell you exactly what to avoid. From my preliminary analysis, I'd cross-check my results if there is more than gather stream term in a statement. It works most of the time, but as you found out, ...

We will put together a list of issues (bugs,quirks) that we and our users (you) are finding. Hopefully that will help.

Nik