4 Replies Latest reply on Jan 8, 2009 5:16 PM by ryta1203

    Passing streams between Kernels in Brook+

    ryta1203
      The way I understood it, or the way it was explained to me was that you have to ping pong due to the stream model.

      What is wrong with this?:

      streamRead(Fs1to4_1, F1to4);
      streamRead(Fs5to8_1, F5to8);
      streamRead(Fs9_1, F9);
      mcollid_s(Fs1to4_1, Fs5to8_1, Fs9_1, fs1to4_1, fs5to8_1, fs9_1, GEOs, ss, G, Fs9_2, Fs5to8_2, Fs1to4_2);
      advection1_s(Fs1to4_2, Fs5to8_2, Fs9_2, GEOs, es, gx, gy, mx, my, rs, Fs9_1, Fs5to8_1, Fs1to4_1);
      streamWrite(Fs9_1, F9);
      streamWrite(Fs1to4_1, F1to4);
      streamWrite(Fs5to8_1, F5to8);


      advection1_s does nothing at the moment. I get garbage for a result. However, if I do this:


      streamRead(Fs1to4_1, F1to4);
      streamRead(Fs5to8_1, F5to8);
      streamRead(Fs9_1, F9);
      mcollid_s(Fs1to4_1, Fs5to8_1, Fs9_1, fs1to4_1, fs5to8_1, fs9_1, GEOs, ss, G, Fs9_2, Fs5to8_2, Fs1to4_2);
      streamWrite(Fs9_2, F9);
      streamWrite(Fs1to4_2, F1to4);
      streamWrite(Fs5to8_2, F5to8);

      Then I get the proper results. How do you "ping pong" in Brook+? I need to be able to send streams from one kernel to the next (output to input) without going back to the CPU (as this would be terribly slow and would make a GPU solution irrelevant).

      Thanks in advance.
        • Passing streams between Kernels in Brook+
          gaurav.garg

          Try calling error() and errorLog on your output streams and see if you get any information.

          Something like -

          if(stream.error())

          {

              std::cout << stream.errorLog();

          }

            • Passing streams between Kernels in Brook+
              ryta1203
              if(Fs1to4_1.error())
              printf("%s\n", Fs1to4_1.errorLog());


              This did nothing. Any ideas?

              Even if I write the stream out and then read it back in I get garbage, but if I don't call the function at all (which does NOTHING, it's literally empty) then all is ok, even if I do the write out, read in and write back out again.

              I only get the problem when calling the second kernel, even if I write out and read back in before calling the second kernel.
                • Passing streams between Kernels in Brook+
                  gaurav.garg

                  Now I get it. You are calling a kernel that is not writing back to output. Right? Specifying a stream as output makes it bound as color buffer and Brook+ doesn't guarantee the output stream data value to remain same as before calling kernel in case you failed to write to that output stream in kernel.

                    • Passing streams between Kernels in Brook+
                      ryta1203
                      Originally posted by: gaurav.garg

                      Now I get it. You are calling a kernel that is not writing back to output. Right? Specifying a stream as output makes it bound as color buffer and Brook+ doesn't guarantee the output stream data value to remain same as before calling kernel in case you failed to write to that output stream in kernel.


                      If in advection1_s I make:

                      output streams = input streams

                      Then all is ok, so yes, it sounds like what you are saying is true; HOWEVER, this brings me to another question:

                      Since there are no bidirectional streams in Brook+, it is necessary for every index you want to remain unchanged (for a ping pong example) that you need to explicitly state this within the kernel, thus having different code paths OR is it cheaper to assign the streams before the "real" kernel code within the kernel, thus avoiding the branch but adding more assignment statements?

                      1. Is this correct?
                      2. What kind of penalty does this incur?
                      3. Have you seen this situation a lot? If so, what have you done that is better than the proposed solution and if not is there going to be anything addressing this large issue (this is very commin in many kernels)?