Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: clBuildProgram return 1

  1. #11
    Senior Member
    Join Date
    Nov 2009
    Posts
    118

    Re: clBuildProgram return 1

    how much C++ishness should be used
    It's a c++ API so I would say : full c++ usage :P

  2. #12
    Junior Member
    Join Date
    Dec 2009
    Posts
    2

    Re: clBuildProgram return 1

    I've just had the same problem: clBuildProgram returning 1.

    The issue was:

    unsigned char GetPix ( unsigned char* Picture, unsigned int width, unsigned int height, unsigned int x, unsigned int y )

    #define GETPIX(xz,yz) GetPix ( Picture, width, height, x+xz, y+yz );i++;

    __kernel void WireFrame( __global unsigned char* Picture, __global unsigned char* WireFrame, unsigned char delta )
    The problem was that I did not have the right memory space chosen for Picture in GetPix function, I've commented out the #define line and the clBuildProgram returned right error with all the information, gathered by clGetProgramBuildInfo procedure. (BTW: clGetProgramBuildInfo returned only the source code with clBuildProgram returning 1)

    IMHO issue is inside #defines, when a line with #define code has an error, then OpenCL Builder has issues finding the line with an error and it returns nothing.

  3. #13
    Senior Member
    Join Date
    Jul 2009
    Location
    Northern Europe
    Posts
    311

    Re: clBuildProgram return 1

    My 2 cents:
    I'd suggest being very careful about trying to check for things like the local work group size being evenly divisible into the global work group size. The reason for this is that you can check for some of them easily, but others require internal knowledge of the runtime/device state. (Such as checking that the total sum of local memory will fit on the device since this can be declared in the kernel as well as through the runtime, and hence requires access to the compiled kernel.)

    I wonder if it is really better to provide a C++ interface that catches some (rather arbitrary) subset of the runtime errors at that level, or to rely on the actual OpenCL implementations to report back errors. E.g., in the case of incompatible local/global sizes, the clEnqueueNDRangeKernel command should have reported an error.

    The OpenCL API provides a detailed error reporting mechanism through the context call back function. I know this is implemented on MacOS X to provide detailed, descriptive error messages for almost all errors. (E.g., it will tell you which of the local/global dimensions are not compatible, or that you are trying to use X bytes of local memory when you only have Y, in addition to returning a CL_ERROR code.)

    I would think that using the context callbacks to get error codes from the runtime, and reporting those to the user would be more robust and generic. This would allow (and, more importantly, encourage) the vendors to provide better error checking and reporting, without having the C++ API re-implement some subset of the same error-checking as the vendors.

    Of course it may be that more error checking is always better, but it will complicate the C++ API code.

  4. #14

    Re: clBuildProgram return 1

    I didn't realize the call back functions reported such detail. I would agree it would be cleaner to keep all error checking at the same abstraction layer. Now the fun C++ trick will become registering a callback function to grab the error message text to dump into a C++ exception. Especially since the call back is registered on the context, but could be triggered by any number of threads simultaneously. How is the user suppose to map a notification function invocation back to the thread that triggered the error?

  5. #15
    Senior Member
    Join Date
    Jul 2009
    Location
    Northern Europe
    Posts
    311

    Re: clBuildProgram return 1

    You can pass user private data into the context callback (if I remember correctly) which can then be mapped to the thread by the user.

    Also, the detail of the provided information may vary from platform to platform. My only experience with the context call back is on Apple's platform where it is very good. (They also provide the cool ability to dump all context messages to the console by setting CL_LOG_ERRORS=stdout.)

  6. #16

    Re: clBuildProgram return 1

    I see the "user_data" argument to clCreateContext. But that still doesn't help much for mapping error messages back to the thread that incurred it. For example, a main thread could set up a context with two devices.

    Code :
    main thread:
    context = Context([device1, device2], pfn_notify)

    A thread is then spawned to handle computation on the two separate devices, and then they both do something nasty to invoke an error in the OpenCL implementation:

    Code :
    thread1:
    queue = CommandQueue(context, device1)
    // do something nasty

    Code :
    thread2:
    queue = CommandQueue(context, device2)
    // do something nasty

    Then pfn_notify will be invoked twice, and even if user_data contained the pointers to each of the threads, it couldn't know which caused the error. The problem is this sentence in the standard, "This callback function may be called asynchronously by the OpenCL implementation." If we were guaranteed that the callback function was executed by the same thread that caused the error we could store the error message in thread local data and recover it later. This is how 'errno' works in the posix standard.

    Or am I missing a trick somewhere?

    -Brian

  7. #17
    Senior Member
    Join Date
    Jul 2009
    Location
    Northern Europe
    Posts
    311

    Re: clBuildProgram return 1

    I think you're right. I've always figured I'd keep one context per thread to avoid having to manually lock around CL calls so then my mapping would work.

Page 2 of 2 FirstFirst 12

Similar Threads

  1. return value about glAttachShader
    By neol in forum OpenGL ES general technical discussions
    Replies: 0
    Last Post: 08-17-2012, 01:45 AM
  2. clBuildProgram return -45 error
    By xstopka in forum OpenCL
    Replies: 3
    Last Post: 05-07-2011, 05:57 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •