Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: clBuildProgram return 1

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

    clBuildProgram return 1

    Hello,

    How could clBuildProgram return 1?
    After reading the specification and the cl.h i saw that it can't return 1 (just <= 0, success or error).

    Is it a bug?

    my code :

    Code :
    cl::PlatformList platforms = cl::GetPlatformList();
     
    if(platforms.empty())
    {
    	return;
    }
     
    cl::Platform & platform = platforms.front();
     
    cl::DeviceList devices = platforms.front().GetDeviceList(deviceType);
     
    if(devices.empty())
    {
    	return;
    }
     
    cl::Device &	     device		(devices.front());
    cl::Context		     context		(device);
    cl::CommandQueue  commandQueue(context, device);
    cl::Buffer		     buffer		(context, cl::Mem::WRITE_ONLY, ARRAY_SIZE * sizeof(Array::value_type));
    cl::Program	     program	(context, sample::LoadSourceFile("sample1.cl"));
     
    try
    {
    	program.Build();
    }
    catch (std::exception const & e)
    {
    }

    ps:
    I use nVidia 195.55 under vista 64.

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

    Re: clBuildProgram return 1

    Same problem here.

    The examples work, but my code returns 1 instead of an error code or CL_SUCCESS. Did you ever work it out?

    I'm on 32 bit Ubuntu, nvidia 8400M.

    Thanks,

  3. #3
    Senior Member
    Join Date
    Nov 2009
    Posts
    118

    Re: clBuildProgram return 1

    In my case when it returned 1 the source didn't compile. So I manage it as an error. By the way it's a bug, and it should be reported to nVidia (but I don't have an nVidia developer account).

    You have a case in which the source should compile but clBuildProgram return 1?

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

    Re: clBuildProgram return 1

    Yeah...I figured it was a bug. I was on the 195.xx beta driver, and I've since rolled back to 190.29 and the code runs perfectly--without changes. I don't have a developer account either. Is there a way to submit this bug without one?

  5. #5

    Re: clBuildProgram return 1

    I'm curious where those C++ bindings came from? Are they shipping with the NVidia windows sdk? As they look similar to the C++ bindings on the khronos registry page, but not exactly the same: http://www.khronos.org/registry/cl/api/1.0/cl.hpp

    -Brian

  6. #6
    Senior Member
    Join Date
    Nov 2009
    Posts
    118

    Re: clBuildProgram return 1

    It's just a personal c++ binding.

  7. #7

    Re: clBuildProgram return 1

    Ah. They're working on making the one on the registry part of the OpenCL 1.1 standard. We're in the phase of making some major revisions in preparation for that.So any discrepancies or wishes that you have for it, now is a good time to voice them.

    For the most part, it looks exactly the same as what you have.

  8. #8
    Senior Member
    Join Date
    Nov 2009
    Posts
    118

    Re: clBuildProgram return 1

    This is my wrapper API : http://matrem84.free.fr/clapi/html, so the c++ API I wished to use .

    some ideas :
    - all OpenCL call are wrapped
    - transparent retain/release (constructor/destructor/operator =)
    - hard usage of objects
    - all instance are in a valid state as soon as they are instanciated
    - hard usage of enum
    - assert all code constaints (for example parameter constaints from the OpenCL specification)
    - throw exception for all other problems (for example all OpenCL call that don't return CL_SUCCESS)

    and for compatibility with other libs :
    - possibility to import "raw cl_object" to create c++ API objects
    - possibility to export "raw cl_object" from c++ API objects

  9. #9

    Re: clBuildProgram return 1

    Thanks for the feedback. Just to get a discussion started I'm going to ask you about some of your points. Everything I don't ask about assume I agree with.

    Quote Originally Posted by matrem
    - hard usage of objects
    Not sure what you mean by this, do you just mean that all the cl_* types should be an object? If so, I agree.

    Quote Originally Posted by matrem
    - all instance are in a valid state as soon as they are instanciated
    Not sure about this. What if the user wanted to do the following:

    Code :
    cl::Context context;
    if (foo)
      context = cl::Context(CL_DEVICE_TYPE_CPU;
    else
      context = cl::Context(CL_DEVICE_TYPE_GPU;

    This idiom requires a default constructed "NULL" object. Also, for use with standard stl containers is a default constructor required? For example, vector:ush_back could be implemented this way:
    Code :
    template<T>
    class vector {
    push_back(const T& obj) {
      resize(size()+1);
      *this[size()-1] = obj;
    }
    }

    Every class could have a operator bool for testing whether an object was valid. And most class methods could just assert(operator bool()) to pick up the cases when the object was accidentally not initialized properly.

    I do recognize the appeal of being assured the objects are always valid, I just don't see a way of doing this and keeping their use flexible.

    Quote Originally Posted by matrem
    - hard usage of enum
    Is this for compile time type checking to make sure a function is passed a proper constant value? I like this idea.

    Quote Originally Posted by matrem
    - assert all code constaints (for example parameter constaints from the OpenCL specification)
    I like this idea since the error codes returned by OpenCL can be less than informative. The assertions can contain reasonable error messages. Last week it took me a good part of a day to discover that my global work size was not divisible by the local work size. Something an assertion like this could have picked up easily.

    Ultimately, the API has to come to a decision about how heavy weight it should be. Or from the other view point, how leaky the implementation should be. This paragraph is in the bindings for the registry:
    * The bindings themselves are lightweight and correspond closely to the
    * underlying C API. Using the C++ bindings introduces no additional execution
    * overhead.
    For example this can be seen in the different way chosen to wrap "clCreateKernelsInProgram". Your signature is this:
    Code :
    KernelList cl::Program::CreateAllKernels()

    The registry's is this:
    Code :
    cl_int cl::Program::createKernels(VECTOR_CLASS<Kernel>* kernels)

    Return by value can be expensive compared to an output argument. Also, is there a good reason to choose std::list instead of std::vector? vectors are typically more performant for this sort of operation. (Note, the registry's version should take a reference instead of a pointer, that will be changed.)

    So some of the design comes down to the slightly subjective decision about how much C++ishness should be used. For the clCreateKernelsInProgram example your design is actually easier to eventually wrapping into higher level languages (python, java, etc). Thanks for the feedback. I'd love to hear anymore specific feedback you have.

    -Brian

  10. #10
    Senior Member
    Join Date
    Nov 2009
    Posts
    118

    Re: clBuildProgram return 1

    Not sure what you mean by this, do you just mean that all the cl_* types should be an object? If so, I agree.
    Yes, use object as soon as it's possible.

    Not sure about this. What if the user wanted to do the following:
    You example can be simplified in one line but in the general case, it will use pointer (raw, scoped, or shared).
    I think that's the way a UML relation with 0..1 multiplicity should be implemented.

    Also, for use with standard stl containers is a default constructor required
    I don't think so, It seems copy constructor and operator = are enough. http://www.sgi.com/tech/stl/Container.html (Value Type). But in case of container which need default constructible object I'll use shared_ptr.

    Is this for compile time type checking to make sure a function is passed a proper constant value? I like this idea.
    Yes, I should have say : maximize compile time checking
    Ultimately, the API has to come to a decision about how heavy weight it should be. Or from the other view point, how leaky the implementation should be. This paragraph is in the bindings for the registry:
    I was talking about debug assertion, so lightweight assertion. But perhaps it could be good to use std::logic_error. Personally I think debug assertions are sufficient (By the way if developer run in release an invalid code, an exception will be raised because cl call won't return CL_SUCCESS).

    Return by value can be expensive compared to an output argument
    I asked myself about always passing by reference instead of return by value, in case there is a copy constructor call.
    In fact I only use this optimization (reference usage) if their is a real penalty. In many case compilers use RVO http://en.wikipedia.org/wiki/Return_value_optimization.
    I prefer to use the return syntax, but it's not really an important wish

Page 1 of 2 12 LastLast

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
  •