cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

nberger
Adept I

Brook+ warnings and broken code

0 Likes
7 Replies
nberger
Adept I

I just found that the warnings are not associated with the kernel in question but with reduction kernels - but I would of course still like to know what they mean...
Nik
0 Likes
udeepta
Staff

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: nberger 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.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...


0 Likes

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.x*parameters.x+parameters.y*parameters.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.x*parameters.x+parameters.y*parameters.y);
result = lookup[index].x * temp;
}
0 Likes

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

tempsum = tempsum + 2.0f*(parameters.x * parameters.x * lookup[index].x
+ parameters.y * parameters.y * lookup[index].x
+ parameters.x * parameters.y * lookup[index].y
- parameters.y * parameters.x * lookup[index].y);

while the equivalent

parpart = 2.0f * parameters.x * parameters.x * lookup[index].x;
tempsum = tempsum + parpart;
parpart = 2.0f * parameters.y * parameters.y * lookup[index].x;
tempsum = tempsum + parpart;
parpart = 2.0f * parameters.x * parameters.y * lookup[index].y;
tempsum = tempsum + parpart;
parpart = 2.0f *parameters.y * parameters.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...
0 Likes

Thanks for finding it Nik. I have filed a bug for this one.

Meanwhile, it is a good idea, as you pointed out, to not have "long statements involving gather". For now, I always write cpu code to run a sanity check on my Brook+ results. 😐

0 Likes
nberger
Adept I

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

Nik
0 Likes

Nik,

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.

 

0 Likes