5 Replies Latest reply on Sep 7, 2010 4:23 AM by himanshu.gautam

    [BUG] crash inside clBuildProgram()

    davibu

      The kernel available at this link http://davibu.interfree.it/tmp/kernel.cl causes a crash inside clBuildProgram().

      This bug can easy be verified by pasting the above kernel source inside the StreamKernelAnalyzer. It will crash as soon you hit the Compile button.

      The problem seems to be triggered by placing a "return;" inside few nested "if() { }".

      I have also experiencing very long compilation time while working on the above kernel (i.e. up to 290 seconds). While the same kernel can be compiled for AMD CPU OpenCL device, NVIDIA OpenCL and Apple OpenCL in less than 1 second.

       

        • [BUG] crash inside clBuildProgram()
          HarryH

          I can confirm this on my system. It seems to compile Init, InitFrameBuffer and

          AdvancePaths_Step1 successfully, it at least dumps a normal looking .isa file.

          Then after a while a segmentation fault follows. Not using the SKA compiling on

          linux 64 bits for Cypress.

            • [BUG] crash inside clBuildProgram()
              himanshu.gautam

              hi all,

              I  confirm that the code mentioned takes a lot of time in kernel analyzer,but it can be explained.

              The kernel Analyzer do not do just the compiling work, in addition it also generates a lot of information regarding the kernel's performance for various GPUs.Refer to http://developer.amd.com/gpu/ska/Pages/default.aspx

              I tried the kernel code in a test program,and it compiled from clBuildProgram within a second.

              As far as the issue regarding the return statement inside an if is there,I tried the following simple test kernel,and it compiles.Although it is not recommended to use it in case you are using a barrier statement.

              #pragma OPENCL EXTENSION cl_amd_printf: enable void __kernel mykernel() { int xGlobal=get_global_id(0); int numGlobalWorkItem=get_global_size(0); if(xGlobal>numGlobalWorkItem/2) return; else printf("half kernel executed correctly"); }

                • [BUG] crash inside clBuildProgram()
                  davibu

                   

                  Originally posted by: himanshu.gautam hi all,

                   

                  I  confirm that the code mentioned takes a lot of time in kernel analyzer,but it can be explained.

                   

                  The above kernel does crash the kernel analyzer as confirmed by HarryH. I'm talking of the Kernel Analyzer included in SDK 2.2.

                   

                    • [BUG] crash inside clBuildProgram()
                      HarryH

                       

                       

                       

                       

                      The above kernel does crash the kernel analyzer as confirmed by HarryH. I'm talking of the Kernel Analyzer included in SDK 2.2.


                        I did not use the SKA but compiled it with a small utility I've written to check

                      kernel sourcefiles for errors. It does nothing except read the kernel and compile it

                      using cLBuildProgram. I can confirm this kernel crashes clBuildProgram on Linux

                      64 bits. So it crashes on both Windows and Linux.

                      EDIT To be more precise I think it crashes $ATISTREAMSDKROOT/bin/x86_64/clc

                      the OpenCL compiler on Linux in my case

                        • [BUG] crash inside clBuildProgram()
                          himanshu.gautam

                          davibu,

                          I have rechecked the code in ska which came with SDK 2.2,

                          on vista x64.IT took about 10 minutes,but did compiled

                          and generated statistics for some  gpus.

                          Please send in information about your system comfiguration

                          and SDK & Driver details, so that i can reproduce the exact

                          problem here.

                          Regarding the delay in SKA the problem has been confirmed.