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...
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. 😐
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.