4 Replies Latest reply on Jun 18, 2014 2:25 AM by pinform

    clBuildProgram crash


      This kernel runs fine on my computer on a CPU device and the CodeXL Kernel Analyzer verifies it should work on a wide variety of cards - everything HD5k or newer for image support. I'm unfortunately currently stuck with a HD4870 and therefore cannot test it myself. On my roommates computer, however, clBuildProgram reports an unexpected exception, both in my own host application and the Kernel Analyzer. We installed new drivers, the APP SDK and CodeXL but nothing seems to work. Is this a driver bug or is the code actually somehow wrong?


      typedef struct {
      float4 orig;
      float4 dir;
      } CLRay;
      typedef struct {
      float2 uv;
      float t;
      int id;
      } CLResult;
      typedef struct {
      float4 a1, a2, a3;
      } CLTriangle;
      typedef struct {
      float4 nor, col;
      } CLTriangledata;
      kernel void fill_image( image2d_t img,
      constant CLRay * ray,
      constant CLResult * result,
      global CLTriangledata * triangledata,
      float N) {
      const int2 id = (int2){get_global_id(0), get_global_id(1)};
      const int id1d = id.y*get_global_size(0)+id.x;
      int res = result[id1d].id;
      float4 col = (float4).0f;
      col = pow(triangledata[res].col, 2.2f) * fabs(dot(ray[id1d].dir, triangledata[res].nor));
      float4 oldcol = read_imagef(img, sampler, id);
      write_imagef(img, id, (oldcol*(N-1.0f)+col)/N);
        • Re: clBuildProgram crash

          Hi msqrt,


          Can you share the exception/error generated by clBuildProgram()? It will help us debug the issue.




            • Re: clBuildProgram crash

              When running it on my own host, visual studio reports an access violation at memory location 0x10 or 0x8, the CodeXL Kernel Analyzer reports an unhandled exception, so I can't get an actual error message.


              The program builds fine if I compile the kernel offline with the Kernel Analyzer and just hand over the binaries, so the difference would seem to be compiler related.


              As I fixed this, a new problem emerged. Another kernel gives CL_OUT_OF_RESOURCES on clEnqueueNDRangeKernel, but this is probably something caused by my own code - does not seem terribly easy to debug, though. I already ruled out both local and global memory running out and reading or writing invalid array locations. I'm not sure how high my register usage is, but I think that should hinder performance instead of not working at all.