7 Replies Latest reply on Jun 10, 2008 6:51 PM by udeepta@amd

    Brook+ warnings and broken code

    nberger
        • Brook+ warnings and broken code
          nberger
          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
          • Brook+ warnings and broken code
            udeepta@amd

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


              • Brook+ warnings and broken code
                nberger
                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;
                }
                  • Brook+ warnings and broken code
                    nberger
                    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...
                • Brook+ warnings and broken code
                  nberger
                  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
                    • Brook+ warnings and broken code
                      udeepta@amd

                      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.